QualiBooth
Français

Corriger une fois, corriger partout

Des centaines de problèmes. Une poignée de corrections.

Votre en-tête, votre navigation et votre pied de page apparaissent sur chaque page : un seul lien défectueux s’y trouvant est donc signalé sur chaque page, lui aussi. Le Regroupement par composant rassemble ces constats par l’élément sur lequel ils ont été trouvés, si bien qu’une exécution d’analyse se lit comme la courte liste des composants à corriger - classés selon le nombre de problèmes que chaque correction élimine.

Analyser mon site gratuitement Le voir sur votre site
Une ligne par élément
et non une par problème et par page
Les pires en premier
selon les problèmes qu’une seule correction élimine
Le panneau Fix once, fix everywhere d’un rapport d’analyse QualiBooth, avec la part des problèmes corrigeables au niveau des composants.

Le même bug, compté sur chaque page

Votre site est construit à partir de gabarits. Votre liste de problèmes devrait l’être aussi.

Tous les scanners rapportent page par page, car c’est là qu’ils ont trouvé le problème. Sur un site à gabarits, cela multiplie un seul défaut par le nombre de pages où il apparaît : un bandeau cookies avec un bouton sans libellé devient quatre cents constats, et le rapport censé vous dire par où commencer vous dit que tout est urgent. Le Regroupement par composant lit les mêmes résultats dans l’autre sens - par élément - parce que c’est ainsi que votre équipe les corrige.

Ce que montre une liste de problèmes à plat

Chaque constat, sur chaque page, une ligne par constat.

  • Les liens doivent avoir un texte discernable - /pricing
  • Les liens doivent avoir un texte discernable - /about-us
  • Les liens doivent avoir un texte discernable - /contact
  • …et le même constat sur 397 autres pages.

Ce que montre le Regroupement par composant

Un élément, chaque page où il échoue, chacun de ses problèmes.

  • footer nav a.social - 400 pages, 2 types de problèmes, 800 problèmes.
  • Corrigez-le une fois dans le gabarit du pied de page, et les 800 disparaissent.
  • Gravité par page : 400 pages critiques, 400 pages de gravité moyenne.
  • Classé par rapport au reste de l’exécution, pour que vous sachiez qu’il passe en premier.

Ce que vous dit chaque fiche d’élément

Tout ce qu’il faut pour décider quoi corriger en premier

Chaque ligne est un élément, pas un problème. Elle réunit tous les contrôles que cet élément échoue et les chiffres qui vous disent ce que vaut sa correction.

  • 01

    Classé selon ce qu’une correction élimine

    Les éléments sont ordonnés selon les problèmes que leur correction éliminerait, puis selon le nombre de pages où ils apparaissent, puis selon la gravité. Le haut de la liste est toujours l’endroit où une seule modification a le plus d’effet.

    Classement

  • 02

    Pages touchées, par gravité

    Un chiffre par niveau de gravité présent sur l’élément : le nombre de pages qui portent un problème de ce niveau. Un niveau que l’élément n’a pas est omis plutôt qu’affiché à zéro.

    Gravité

  • 03

    Part de l’exécution entière

    Chaque pourcentage est calculé sur l’ensemble des problèmes trouvés par l’exécution, et non sur ce qui est à l’écran - « 12 % de l’exécution » signifie donc bien 12 % de l’exécution, quel que soit le filtre.

    Impact

  • 04

    Tous les problèmes de l’élément

    Un même lien peut manquer de contraste et être dépourvu de libellé - deux corrections, un seul composant. En dépliant une fiche, vous obtenez chaque contrôle avec sa gravité, son niveau WCAG, ses occurrences, ses pages et un lien vers les conseils de correction.

    Détail

  • 05

    Filtrer par gravité et par moteur

    Limitez la liste aux problèmes critiques, aux constats que seul Deep Scan produit, ou cherchez par sélecteur ou par nom de problème. Les totaux et pourcentages sont recalculés sur ce qui reste, pour que les chiffres correspondent toujours à la liste.

    Tri

  • 06

    Droit au code

    Copiez le sélecteur CSS de l’élément, ouvrez le rapport d’une page touchée, ou ouvrez la page en direct dans le Development Assistant ou Agora avec l’élément mis en surbrillance.

    Correction

L’essentiel de la dette d’accessibilité d’un site à gabarits se concentre dans quelques composants partagés. Le Regroupement par composant vous montre lesquels - et quelle part du rapport chaque correction fait disparaître.

Des chiffres qui tombent juste

Des chiffres à présenter tels quels à un product owner

Une vue regroupée n’est utile que si ses chiffres sont justes. Chacun est donc compté, pas estimé - et lorsqu’un chiffre est un minimum plutôt qu’une valeur exacte, le rapport le précise.

  • Les pages sont comptées une seule fois par élément, même lorsqu’il échoue plusieurs contrôles sur des pages différentes.
  • Filtrer un élément reconstruit ses chiffres à partir des problèmes restants : « Critical only » n’affiche donc jamais de totaux incluant des problèmes mineurs.
  • Les noms de problèmes proviennent du même catalogue que le rapport par page : un même problème porte le même nom partout.
  • Les exécutions volumineuses conservent les éléments les plus coûteux, et le rapport indique combien il en liste sur combien il en a trouvé.
Une fiche d’élément dépliée : le sélecteur, les pages touchées, les problèmes, la part de l’exécution et chaque contrôle que l’élément échoue.

Le tableur que personne n’a envie de construire

Le tri que votre équipe fait à la main après chaque audit - terminé dès la fin de l’analyse

Transformer un export page par page en liste de composants n’a rien de difficile. C’est simplement long, et il faut le refaire après chaque analyse - c’est pourquoi, en général, on ne le fait pas.

  • Exporter tous les problèmes dans un tableur

    Regroupés automatiquement à la fin de l’exécution

  • Trier par sélecteur et fusionner les doublons

    Une ligne par élément, avec chaque contrôle qu’il échoue

  • Compter les pages que chaque élément casse

    Pages touchées, par gravité, sur chaque fiche

  • Déterminer quelle correction en élimine le plus

    Les pires en premier, selon les problèmes que chaque correction élimine

  • Tout recommencer après la prochaine mise en production

    Chaque exécution planifiée est regroupée de la même façon

Les problèmes propres à une page restent à leur place

Le Regroupement par composant ne liste que ce qui échoue de la même façon sur plus d’une page. Tout le reste figure toujours dans le rapport par page, et les constats de niveau page qui se répètent sur tout le site - comme une langue de page manquante - sont listés sous Whole page, car il s’agit du même défaut partout, même sans composant à corriger.

Comment ça marche

Rien à configurer. Chaque exécution d’analyse planifiée est regroupée dès qu’elle se termine.

  1. 01

    Analysez comme d’habitude

    Votre analyse planifiée ou à la demande s’exécute exactement comme avant, avec le moteur statique et Deep Scan, sur ordinateur et sur mobile.

  2. 02

    Regroupé par élément

    À la fin de l’exécution, QualiBooth compare toutes les pages et regroupe les constats qui se répètent sur un même élément, pour les deux moteurs.

  3. 03

    Classé selon ce qu’il fait disparaître

    Les éléments sont ordonnés selon les problèmes que leur correction éliminerait, et la synthèse de l’exécution affiche la part corrigeable au niveau des composants.

  4. 04

    Corrigez une fois, vérifiez

    Corrigez le composant dans votre code. L’exécution suivante montre qu’il a disparu de toutes les pages où il apparaissait.

L’onglet Shared components d’un rapport d’analyse QualiBooth, filtré par gravité et par moteur.

Dans votre rapport

La première chose que vous voyez dans une exécution d’analyse

Le rapport d’exécution s’ouvre sur ses composants partagés. L’onglet Overview montre quelle part de l’exécution est corrigeable au niveau des composants et les trois éléments les plus coûteux ; l’onglet Shared components contient la liste complète.

  • Les éléments partagés et la part des problèmes corrigeables au niveau des composants, à côté du score.
  • Un panneau Fix once, fix everywhere avec les éléments les plus coûteux, le premier déjà déplié.
  • Un onglet Shared components avec tous les éléments, filtrables par gravité, par moteur et par texte.
  • Un statut clair pendant qu’une exécution est en cours, ou lorsqu’aucun élément ne se répète d’une page à l’autre.
1
ligne par élément, et non par problème
2
moteurs d’analyse regroupés ensemble
2
fenêtres d’affichage, ordinateur et mobile
0
configuration - inclus dans toutes les offres

Les questions qu’on nous pose

Qu’est-ce qu’un composant partagé ?
Tout élément qui échoue le même contrôle d’accessibilité sur plus d’une page d’une exécution d’analyse - généralement un en-tête, une navigation, un pied de page, un bandeau cookies ou une autre partie du site issue d’un gabarit. Les constats qui concernent la page entière plutôt qu’un élément sont eux aussi regroupés, et listés sous Whole page.
Dois-je configurer quelque chose ?
Non. Le Regroupement par composant s’exécute automatiquement sur chaque exécution d’analyse planifiée dès qu’elle se termine, pour les résultats sur ordinateur comme sur mobile. Il est inclus dans toutes les offres.
Les constats Deep Scan sont-ils inclus ?
Oui. Les constats du moteur statique et ceux de Deep Scan sont regroupés ensemble, et vous pouvez filtrer la liste par moteur pour n’en voir qu’un seul.
Le regroupement masque-t-il des problèmes ?
Non. Chaque constat figure toujours dans le rapport par page. Le Regroupement par composant est une seconde vue des mêmes résultats, organisée par l’élément qui les porte, et ses pourcentages sont toujours calculés sur l’ensemble des problèmes de l’exécution.
Pourquoi n’y a-t-il pas de regroupement pour l’une de mes anciennes exécutions ?
Les exécutions terminées avant la sortie du Regroupement par composant ne sont pas analysées rétroactivement. La prochaine analyse de cette configuration l’inclura. Le regroupement nécessite aussi qu’au moins deux pages soient analysées avec succès, puisqu’il fonctionne en comparant les pages.
En quoi cela aide-t-il mes développeurs ?
Il transforme le rapport en tâches qui correspondent à votre code. Chaque fiche fournit le sélecteur CSS exact à copier, des liens vers une page touchée, et ouvre la page en direct dans le Development Assistant ou Agora avec l’élément mis en surbrillance - la correction commence ainsi dans le composant, pas dans une chasse page par page.

Découvrez quelle part de votre rapport tient en une seule correction

Lancez une analyse gratuite, ou laissez-nous vous présenter les composants partagés de votre site lors d’une démo.

Analyser mon site gratuitement Réserver une démo