Un site que certains visiteurs ne peuvent pas utiliser est un site qui refuse des clients en silence. Nous faisons du niveau AA des WCAG 2.2 le socle d'ingénierie de chaque projet, et nous le vérifions par la mesure plutôt que de l'affirmer dans une plaquette.
Pourquoi
La réglementation sur l'accessibilité ne cesse de s'étendre : règles du secteur public, législation sur le handicap appliquée au web, exigences de consommation sur un nombre croissant de marchés. Nous sommes des ingénieurs, pas des juristes, et nous ne donnons pas de conseil juridique. Ce que nous pouvons dire simplement : un site construit et vérifié selon les WCAG 2.2 AA s'appuie sur le référentiel que ces régimes citent, et un site qui l'ignore porte un risque que vous n'avez pas budgété.
La structure qui sert un lecteur d'écran sert aussi un robot d'indexation : de vrais titres dans l'ordre, des champs étiquetés, des textes descriptifs sur les images, des liens qui disent où ils mènent. Le travail d'accessibilité et le travail de référencement se renforcent mutuellement, et c'est pourquoi nous les traitons comme une seule discipline plutôt que deux factures.
Un contraste confortable, des zones tactiles généreuses, une page qui se parcourt au clavier, un mouvement qui respecte vos réglages : les visiteurs nomment rarement ces choses, mais ils les ressentent comme du soin. Leur absence se lit comme de la négligence, précisément sur la page où vous demandez qu'on vous fasse confiance.
En pratique
Le référentiel semble abstrait tant qu'il n'est pas appliqué. Voici ce qu'il signifie concrètement dans chaque site que nous livrons.
Vérification
Chaque page compilée est auditée selon les WCAG 2.2 AA aux largeurs mobile, tablette et ordinateur, dans les thèmes clair et sombre, à chaque modification. Une violation ne produit pas un rapport que quelqu'un lira peut-être ; elle fait échouer la compilation, et une compilation en échec ne peut pas se déployer. Les régressions d'accessibilité sont interceptées avant qu'un visiteur puisse les rencontrer.
Les ratios de contraste sont calculés, les tailles de cible mesurées en pixels, l'ordre des titres analysé, et les mêmes vérifications s'exécutent sur chaque version linguistique de chaque page. Ce qu'une liste de contrôle affirme, la suite de tests le prouve.
Les vérifications automatisées attrapent beaucoup de choses, mais pas tout. Avant la mise en ligne, nous parcourons aussi le site comme le ferait un visiteur avec des besoins d'accès réels : navigation entièrement au clavier, lecture à des tailles de texte agrandies, et passage des formulaires en gardant à l'esprit les annonces du lecteur d'écran.
Intégré
Rattraper l'accessibilité est la façon coûteuse de l'obtenir : recolorer une palette de marque qui n'a jamais atteint le contraste requis, reconstruire des composants incapables de recevoir le focus, réécrire des pages dont les titres étaient de la décoration. Nous prenons le chemin inverse. Le système de design est vérifié pour le contraste dans les deux thèmes avant qu'une seule page ne soit composée, les composants interactifs sont construits clavier d'abord, et l'audit s'exécute dès le premier déploiement du projet, pas au dernier. Au lancement, l'accessibilité n'est pas une tâche sur une liste ; c'est une propriété du code que les tests maintiennent vraie.
Tout ce que comprend un projet de site web Accessible dans chaque langue, y compris de droite à gauche Comment se déroule un projet
Posez-nous vos questions sur le référentiel, ou demandez-nous d'examiner votre site actuel. Écrivez-nous via le formulaire de contact ou à sales@wwi.dev.