La page d'accueil s'ouvre sur une porte qui se referme, une marche vers le bureau, un sol et un plafond qui apparaissent en fondu, un tableau noir qui bascule en place, une enseigne suspendue et, enfin, une horloge murale dont la trotteuse démarre — sept temps sur un calendrier fixe : porte à 0,5s, marche à 0,75s, sol à 2s, plafond à 2,15s, tableau à 2,35s, enseigne à 2,6s, horloge à 2,7s. Rien de cette séquence n'est orchestré en JavaScript. Chaque temps est une animation CSS par keyframes avec son propre animation-delay, et la « chorégraphie » n'est rien de plus que sept délais choisis pour tomber dans le bon ordre. Il y a une petite flèche circulaire dans le coin qui relance le tout au clic, et ce qui est intéressant, c'est que son code n'a aucune idée que tout ce qui précède est vrai.
Un seul appel, pas sept
Un bouton de relecture naïf devrait connaître chaque élément animé, redémarrer chacun d'eux, et garder cette liste à jour à chaque nouveau temps ajouté à l'intro. Ce n'est pas ce que fait celui-ci. Il appelle hero.getAnimations({ subtree: true }) — une API du navigateur qui renvoie toutes les Web Animations en cours d'exécution n'importe où à l'intérieur de l'élément héroïque, quelles qu'elles soient — et pour chacune reçue, il appelle .cancel() puis .play(). C'est tout le gestionnaire. Ajouter un huitième temps à l'intro plus tard ne nécessite aucune modification de cette fonction ; le navigateur renverra simplement une animation de plus au prochain clic sur le bouton, puisque la fonction ne les a jamais comptées au départ.
Avant que rien de tout cela ne s'exécute, le code vérifie d'abord si hero.getAnimations existe, et si ce n'est pas le cas, il masque le bouton au lieu de brancher le gestionnaire de clic. Un bouton visible mais qui ne fait rien sur un navigateur ancien est pire que pas de bouton du tout — il invite à cliquer puis échoue silencieusement à livrer, ce qui est un échec pire que de ne pas proposer la fonctionnalité.
Les mêmes sept temps n'atteignent jamais les petits écrans
En dessous de 900 pixels de large, la salle de classe cesse d'être un diorama vu de côté et s'empile verticalement, et l'intro qui s'y joue n'est pas une version raccourcie de celle de bureau — c'est une séquence différente et plus courte, avec moins de temps : plafond à 0s, sol à 0,2s, tableau à 0,25s, professeur à 0,65s, légende à 1,05s. La porte, l'horloge murale et le bouton de relecture lui-même sont carrément masqués sur les petits écrans — l'enseigne suspendue au-dessus de la leçon sur ordinateur n'a nulle part où se suspendre une fois que le tableau occupe toute la largeur, elle subit donc le même sort que la porte et l'horloge plutôt que de se retrouver rognée maladroitement. Le mobile n'obtient pas une version plus rapide du même spectacle en sept temps. Il obtient un spectacle en cinq temps, conçu pour la mise en page où il s'exécute réellement.
Ce qui se passe quand le mouvement est désactivé
Une seule règle globale réduit chaque animation et transition du site à une durée quasi nulle dès qu'un appareil visiteur demande prefers-reduced-motion: reduce. Pour la section héroïque, cela signifie que la porte, la marche, le sol, le tableau, l'enseigne et l'horloge ne se déroulent pas sur un calendrier compressé — ils atteignent leur état final quasi instantanément, car il n'existe pas de version raccourcie de la séquence cachée derrière la version complète. C'est un vrai choix de conception avec un vrai compromis : certaines recommandations d'accessibilité privilégient une transition brève mais toujours présente plutôt qu'une coupure nette, sur l'idée qu'un changement de scène soudain peut lui-même surprendre. On a choisi la garantie la plus simple — un réglage d'animation honoré à cent pour cent, sans mouvement résiduel qu'il faudrait vérifier — plutôt qu'une version partiellement réduite qui nécessiterait ses propres tests pour confirmer qu'elle est réellement assez douce.
Ce dont on n'est pas encore sûrs
Element.getAnimations() est largement pris en charge par les navigateurs actuels, mais ça n'a pas toujours été le cas, ce qui explique exactement pourquoi le bouton vérifie sa présence et disparaît plutôt que de la présumer — une petite habitude aussi instructive que fonctionnelle, mais cela signifie qu'un petit nombre de visiteurs sur des navigateurs anciens ne voient aucun bouton de relecture plutôt qu'une version dégradée. On n'a pas cherché à quantifier combien de personnes ça représente réellement, parce que pour l'intro décorative d'un site marketing, la réponse honnête est que ça ne vaut probablement pas le temps d'ingénierie nécessaire pour le savoir.