Sujet : html
-
Images adaptatives avec srcset, sizes et picture
srcset avec des descripteurs de largeur, associé à un attribut sizes, permet au navigateur de choisir le fichier image le plus petit qui remplit l'emplacement pour le viewport et la densité de pixels actuels ; les descripteurs x servent des images de taille fixe à plusieurs densités ; picture avec des éléments source gère la direction artistique et le repli de format. Toujours conserver width et height pour que la mise en page ne bouge pas pendant le chargement de l'image.
-
Validation native des formulaires HTML : required, pattern, type et la Constraint Validation API
HTML valide les contrôles de formulaire avant la soumission sans aucun script : required, minlength, min/max, pattern et les types d'entrée saisis définissent des contraintes, le navigateur bloque la soumission et affiche un message, le CSS peut styliser :user-invalid, et la Constraint Validation API expose le même état aux scripts. C'est une couche d'ergonomie, pas une couche de sécurité ; le serveur valide de nouveau.
-
Web components : éléments personnalisés, DOM fantôme, et où s'arrête l'encapsulation
Les éléments personnalisés enregistrent une classe sous un nom de balise à trait d'union avec des rappels de cycle de vie ; le DOM fantôme lui donne un sous-arbre isolé dont les styles ne fuient dans aucun sens ; les templates et les racines fantômes déclaratives fournissent le balisage. Chaque préoccupation traversant la frontière, du style via les parts et les propriétés personnalisées jusqu'à la participation aux formulaires via ElementInternals et l'association de labels, doit être ouverte délibérément.
-
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é.
-
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.
-
Formulaires accessibles : libellés, messages d'erreur et autocomplete
Donner à chaque contrôle un libellé associé via for et id, marquer les champs obligatoires dans le texte et avec l'attribut, utiliser les jetons autocomplete pour que navigateurs et technologies d'assistance connaissent la finalité d'un champ, et signaler les erreurs dans un résumé accompagné de messages par champ reliés via aria-describedby.
-
dialog contre popover : comportement modal, la couche supérieure et la fermeture légère
dialog avec showModal() est modal : couche supérieure, page rendue inerte, ::backdrop, touche Échap, closedby et form method=dialog ; l'attribut popover fait de n'importe quel élément une superposition non modale de la couche supérieure, qu'un bouton peut basculer sans script, avec fermeture légère en état auto. Utiliser dialog pour les invites bloquantes et les formulaires, popover pour les menus, infobulles et notifications toast.
-
Rôles ARIA : pourquoi un élément HTML natif l'emporte sur un div doté d'un rôle
La première règle d'utilisation d'ARIA du W3C est de préférer un élément ou un attribut HTML natif qui possède déjà la sémantique et le comportement requis ; ARIA ne change que ce qui est communiqué aux technologies d'assistance, jamais ce que fait l'élément. Un div doté de role=button a encore besoin que la focalisabilité, la gestion du clavier et les états soient ajoutés à la main, et chaque erreur reste invisible lors d'un test visuel.
-
Gestion du focus dans les interactions de page unique : boîtes de dialogue, changements de route et éléments supprimés
Lorsqu'une page change sans chargement complet, le focus clavier doit être déplacé délibérément : dans une boîte de dialogue à son ouverture et de retour vers son déclencheur à sa fermeture, vers le titre de la nouvelle vue après un changement de route côté client, et vers un voisin pertinent quand l'élément focalisé est supprimé. Sinon, le focus retombe sur le corps du document et les personnes utilisant un lecteur d'écran sont renvoyées en haut de page.
-
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.
-
details et summary : widgets de divulgation natifs, accordéons exclusifs et hidden until-found
details/summary est un widget de divulgation sans script : l'attribut open affiche le contenu, un attribut name partagé rend un groupe exclusif de sorte que l'ouverture de l'un referme les autres, l'événement toggle signale les changements, et summary est stylé comme display: list-item. Pour un contenu réduit qui doit rester consultable par recherche, hidden=until-found le révèle lors d'une recherche dans la page ou d'une navigation par fragment.
-
Livraison d'images : AVIF et WebP avec solutions de repli, chargement différé et priorité de récupération
Servir les formats modernes via des sources picture avec un attribut type et une img JPEG ou PNG comme repli (ou négocier sur Accept avec Vary), ne charger de façon différée que les images situées sous la première zone visible avec width et height définis, et marquer la plus grande image au-dessus de la ligne de flottaison avec fetchpriority=high plutôt que lazy.
Lisible par machine : JSON