Comment ça marche
Dans le code
Avant la publication, Briks vérifie les couleurs des mots par rapport aux fonds sur lesquels ils se trouvent.
Sur la page en ligne
Après la première publication, il examine la page en largeur ordinateur et en largeur mobile.
Une réparation si nécessaire
Là où les textes sont difficiles à lire, il les corrige une fois.
Ce qui est vérifié à chaque création
Un faible contraste est l'un des défauts d'accessibilité les plus courants sur le web : gris pâle sur blanc, blanc sur une photo claire, une couleur de marque sur une teinte voisine. Briks vérifie le contraste des couleurs dans le code du site avant toute publication, en mesurant chaque couleur de texte par rapport au fond sur lequel elle se trouve réellement.
Le seuil est celui que fixent les règles d'accessibilité, WCAG AA : 4,5 pour 1 pour le texte courant, et 3 pour 1 pour le grand texte, soit 24 pixels et plus, ou environ 19 pixels en gras. Quand une couleur n'atteint pas ce seuil, les mots sur ce fond sont composés dans une couleur lisible.
Après la première publication, Briks examine la page en ligne en largeur ordinateur et téléphone et revérifie le contraste, car certains problèmes n'apparaissent que dans un navigateur, comme du texte sur une image. Si quelque chose est difficile à lire, il le corrige une fois. Il vérifie aussi que chaque page choisie figure dans le menu.
Vérifications supplémentaires pour les applications, et au lancement
Les applications bénéficient d'une seconde lecture de leur code avant publication, centrée sur les erreurs les plus coûteuses : clés secrètes écrites dans des fichiers, écritures dans la base de données sans limite, table de membres que n'importe qui pourrait lire, et requêtes de base de données construites en assemblant des chaînes de texte.
Quand vous passez un site en production, la vérification avant lancement s'exécute d'abord. Elle bloque le lancement pour tout ce qui gênerait une entreprise dès son premier jour : du texte provisoire resté en place, des faits inventés par le brouillon que vous n'avez ni remplacés ni confirmés, des pages sans titre ni description propres pour les résultats de recherche, des liens entre vos pages qui ne mènent nulle part, et l'absence d'une page pour les adresses qui n'existent pas.
Il lit jusqu'à douze pages et essaie jusqu'à quatre-vingts liens. Il n'utilise aucun modèle d'IA, donc il ne consomme aucun crédit.
La vérification approfondie, et ce qui n'est pas vérifié
Une vérification plus complète est à un interrupteur de distance dans les étapes de nouveau projet, et désactivée par défaut. Une fois la première version publiée, Briks l'examine à quatre tailles d'écran et répare ce qui s'affiche mal, comme des éléments qui se chevauchent ou une mise en page qui s'effondre à une certaine largeur. Cela prend quelques minutes de plus et quelques crédits ; une vérification bloque 5 crédits pendant qu'elle s'exécute. Vous pouvez demander la même vérification avec n'importe quelle modification ultérieure.
Pour être clair sur les limites : les vérifications de chevauchement, d'images et de liens ne sont pas lancées à chaque création. Une première création normale reçoit les vérifications de contraste, la vérification du menu et, pour les applications, la lecture du code. Les liens sont vérifiés par la vérification avant lancement, ou par la vérification plus complète quand vous l'activez.
Rien de tout cela ne remplace votre propre regard. Ouvrez l'aperçu sur votre téléphone avant de publier en production, et demandez en termes simples tout ce qui vous semble décalé.
Vérifications avant publication en pratique
Trois exemples d'entreprises, et comment chacune l'utiliserait. Lorsqu'un site est illustré, il s'agit d'un exemple créé avec Briks pour une entreprise fictive, pas d'un client.
- 01Fabricant de bougies
Des mots pâles sur une photographie douce
Une fabricante de bougies veut son titre sur une photo brumeuse du bord de mer. Sur la largeur d'un téléphone, une partie du titre se retrouve sur la zone la plus lumineuse du ciel. C'est le genre de défaut pour lequel la vérification en direct existe : elle examine la page publiée sur ordinateur et sur téléphone, et corrige les mots difficiles à lire.
Saltmarsh Candles est un site exemple créé par Briks pour un fabricant de bougies fictif, pas un client. Ouvrir l'exemple - 02Cabinet d'avocats
Une couleur de marque or clair sur fond blanc
La couleur de marque d'un cabinet d'avocats est un or clair. En texte sur fond blanc, elle est bien en dessous de 4,5 pour 1. Avant la publication, la vérification dans le code la repère et applique au texte sur ce fond une couleur lisible : les pages du cabinet restent donc lisibles dès la première publication.
- 03Entreprise de construction
L'application d'une équipe de chantier, relue avant publication
Une entreprise de bâtiment demande une petite application où ses équipes consignent les chantiers. Avant la publication, son code est relu pour repérer les clés écrites dans des fichiers et les écritures sans limite. Quand l'entreprise la passe en production, la vérification avant lancement trouve aussi un lien vers une page Projects qui n'a jamais été créée, et bloque le lancement jusqu'à correction.
Ce que vous obtenez
- Contraste vérifié dans le code avant la publication, selon WCAG AA
- Revérifié sur la page en ligne, sur ordinateur et sur téléphone, avec une réparation
- Chaque page choisie figure dans le menu avant la publication
- Les applications sont analysées pour repérer les clés écrites dans des fichiers, les écritures sans limite et les requêtes non sécurisées
Bon à savoir
- Une vérification plus complète à quatre largeurs est à portée d'un interrupteur dans les étapes de nouveau projet.
- Publier en production lance une vérification avant lancement, y compris des liens qui ne mènent nulle part.