Sujet : frontend
-
Les formulaires qui déclarent des contraintes HTML natives produisent moins de rejets de validation côté serveur par soumission que les formulaires validés uniquement en JavaScript personnalisé
Hypothèse : le navigateur bloque la soumission interactive d'un formulaire dont les contraintes natives (required, pattern, type, min et max) échouent, tandis que MDN note que l'appel de submit() contourne ce blocage et que novalidate le désactive ; la proposition est que les formulaires portant des contraintes natives reflétant les règles du serveur atteignent le serveur avec moins de rejets par soumission que les formulaires dont les vérifications ne vivent que dans des scripts personnalisés, parce que les vérifications natives continuent de fonctionner quand le script ne se charge pas ou échoue ; un test A/B est proposé, sans résultat avancé.
-
L'intégrité des sous-ressources pour les scripts et feuilles de style tiers
Un attribut integrity sur un élément script ou link porte un hachage SHA-256, SHA-384 ou SHA-512 en base64 du fichier attendu ; le navigateur refuse d'exécuter ou d'appliquer une ressource dont le contenu ne correspond pas. Cela fixe exactement ce qu'un CDN peut livrer, exige le CORS pour les fichiers d'origine croisée, et ne fonctionne donc que pour des ressources à contenu fixe.
-
Favicons et manifeste d'application web : les fichiers à livrer et comment les déclarer
En l'absence de `link rel=icon` déclaré, les navigateurs se rabattent sur /favicon.ico, d'où l'intérêt de garder ce fichier en place ; déclarer un SVG redimensionnable ou un PNG dimensionné avec `link rel=icon`, un `apple-touch-icon`, et un manifeste dont les icônes portent des tailles et un `purpose` (any, maskable, monochrome). Les moteurs de recherche veulent un favicon carré et stable par nom d'hôte.
-
Accessibilité : les quatre principes WCAG appliqués concrètement
Les WCAG 2.2 classent tous les critères de succès selon quatre principes : perceptible, utilisable, compréhensible, robuste. Connaître par principe les manquements les plus fréquents (alternatives textuelles absentes, pièges au clavier, contraste insuffisant, champs non étiquetés, cibles trop petites) permet de repérer de nombreux obstacles sans outil spécialisé ; le niveau AA est l'objectif habituel.
-
Quelle part des défauts d'accessibilité trouvés en audit manuel ou signalés par des utilisateurs avait passé les contrôles automatisés en CI, et quels types de défauts leur ont échappé ?
Question ouverte : les recommandations du W3C WAI sur les outils d'évaluation indiquent que certains contrôles d'accessibilité ne peuvent pas être automatisés et nécessitent une intervention manuelle ; pour des sites qui font tourner un vérificateur automatisé à chaque build, quelle part des défauts trouvés ensuite lors d'un audit manuel ou signalés par des utilisateurs avait passé ce vérificateur, et quels types de défauts expliquent cet écart ?
Lisible par machine : JSON