Les dernières ressources publiées sur Alsacreations.com
Sur le web, on a tendance à concevoir comme si tout le monde utilisait les sites de la même manière. Pourtant, ce n’est pas le cas. Certaines personnes naviguent au clavier, d’autres à la voix, certaines ont des troubles moteurs, visuels ou cognitifs. Et bien souvent, ces difficultés sont invisibles à celles et ceux qui n’en font pas l’expérience.
C’est pour ça que certains choix de design, qui paraissent anodins ou esthétiques, peuvent devenir de vrais obstacles. Le défilement horizontal en est un bon exemple : agréable à regarder pour certains, mais complexe, fatigant, voire inaccessible pour d’autres.
Pour répondre à ces enjeux, il existe des référentiels d’accessibilité numérique : en France par exemple, l’accessibilité numérique est encadrée par le RGAA (Référentiel Général d’Amélioration de l’Accessibilité), qui via une directive européenne transpose les WCAG (Web Content Accessibility Guidelines notamment adoptées aux États-Unis) 2.1 niveaux A et AA en critères testables adaptés au contexte local.
Loin d’être seulement une exigence légale, l’accessibilité numérique sert à rendre le web plus inclusif et à garantir un accès équitable à l’information, permettant au passage d'améliorer l’expérience de toutes et tous.
En rendant les contenus utilisables par le plus grand nombre, elle renforce aussi la satisfaction et la fidélisation, ce qui se traduit souvent par de meilleurs résultats en termes de conversions et d’engagement.
Dans ce contexte, un choix de design revient souvent : les conteneurs à défilement horizontal (galeries, carrousels, barres d’outils…). S’ils paraissent séduisants visuellement, ils posent de vrais problèmes d’accessibilité et d’expérience utilisateur.
Un conteneur à défilement horizontal est une zone où le contenu est affiché côte à côte et nécessite un geste latéral (scroll, swipe ou clic) pour accéder aux éléments non visibles.
Cela peut prendre la forme :
Ce modèle est souvent utilisé pour gagner de l’espace vertical ou créer un effet visuel immersif. Mais il présente des limites fortes.
Contenu manqué : beaucoup de personnes ne voient pas qu’il y a d’autres éléments hors écran, et passent donc à côté d’informations importantes.
Navigation compliquée : au clavier, à la voix ou avec des aides techniques, accéder à ces zones peut devenir un vrai parcours du combattant.
Gestes complexes : maintenir une touche ou un clic tout en défilant latéralement demande une précision difficile pour les personnes avec des troubles moteurs.
Perte de repères : le focus peut disparaître hors champ, rendant la navigation confuse.
Mauvaise compatibilité : selon le navigateur ou l’appareil, l’expérience peut varier et devenir frustrante.
Ces enjeux montrent pourquoi, malgré sa popularité croissante, notamment dans les interfaces desktop (navigateurs de bureau sur grand écran) comme les carrousels de produits en e-commerce, le défilement horizontal ne constitue pas une stratégie optimale pour présenter le contenu à un large public, car il est trop souvent mal réalisé et mal géré par les navigateurs (indépendamment de notre volonté).
Même si, globalement, le défilement horizontal est à éviter, certains composants complexes l’emploient par nécessité.
Pour créer par exemple un carrousel conforme au RGAA, il est recommandé de suivre les pratiques du WAI-ARIA Authoring Practices Guide (APG).
aria-label
ou aria-labelledby
pour nommer la zone, et éventuellement aria-roledescription
(ex. « galerie défilante ») pour préciser son rôle.aria-controls
et étiquettes claires.Tab
pour entrer/sortir, flèches pour défiler, Home
/ End
pour aller aux extrémités.aria-live="polite"
ou une zone masquée (live region) pour les lecteurs d’écran (uniquement dans le cas où il n'y a pas de défilement automatique : en cas de défilement automatique, pas de aria-live. Mais évidemment, le défilement automatique n'est pas du tout conseillé).Même si le défilement horizontal est très en vogue aujourd’hui (notamment dans les interfaces desktop de e-commerce avec les carrousels de produits ou les galeries) cette popularité ne garantit pas pour autant que ce modèle soit réellement efficace.
Les recherches en expérience utilisateur et les retours de terrain montrent qu’un grand nombre de personnes passent à côté de ces contenus défilants sur desktop, ce qui entraîne une interaction limitée. J'en parle d'ailleurs dans un article consacré aux carrousels : Les carrousels (slider) sont-ils vraiment utiles ?.
Les choix de design devraient être guidés par :
Au final, la meilleure tendance reste celle qui place tout le monde au centre.
Les choix de design devraient toujours être guidés par l’inclusion et l’efficacité, plutôt que par les tendances du moment.
Les redirections HTTP sont des mécanismes essentiels pour gérer le routage et la navigation. Comprendre les différences entre les codes 301 et 302 est important pour tout projet web, que ce soit pour intervenir en développement, référencement ou planification. Faisons le tour en détails.
La redirection 301 Moved Permanently indique que la ressource a été déplacée de manière permanente vers une nouvelle adresse, ou URL. Cette redirection signale aux navigateurs et aux moteurs de recherche que l'ancienne URL ne sera plus jamais utilisée.
En cas de refonte de site web : vous souhaitez
En cas de migration HTTPS, c'est une démarche purement technique et globale si votre site vient de passer du protocole non sécurisé HTTP, vers le HTTPS (recommandé) : http://exemple.com → https://exemple.com
La redirection 302 Found (Temporary Redirect) indique une redirection temporaire. L'URL originale reste valide et pourrait être utilisée à nouveau dans le futur.
Les redirections HTTP se font, comme leur nom et protocole l'indique, au niveau du serveur HTTP.
Dans la configuration du serveur web Apache ou dans un fichier .htacess
la syntaxe est historiquement toujours la même, grâce au module rewrite et aux instructions Redirect
ou RewriteRule
en précisant le code de redirection HTTP avec le paramètre R=xxx
.
Redirection 301 :
# Redirection simple avec Redirect
Redirect 301 /ancienne-page /nouvelle-page
# Redirection simple avec RedirectPermanent
RedirectPermanent /ancienne-page /nouvelle-page
Ces deux directives s'utilisent hors du contexte de mod_rewrite contrairement à RewriteRule
qui permet d'ajouter des expressions régulières, des conditions, etc. Pour cela, il faut utiliser RewriteRule
dans un bloc avec RewriteEngine On
:
# Avec RewriteRule
RewriteEngine On
RewriteRule ^ancienne-page$ /nouvelle-page [R=301,L]
# Migration HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# Changement de domaine
RewriteCond %{HTTP_HOST} ^ancien-domaine\.com$ [NC]
RewriteRule ^(.*)$ https://nouveau-domaine.com/$1 [R=301,L]
Redirection 302 :
# Redirection temporaire
Redirect 302 /maintenance /page-maintenance
# Avec RewriteRule
RewriteRule ^promo$ /page-promo-temporaire [R=302,L]
ð¡ Dans ces exemples le paramètre L
signifie Last, soit la dernière règle à suivre : il ne doit pas appliquer les règles suivantes dans le même bloc ou le même fichier de configuration. Cela permet d'optimiser les performances et d'éviter des conflits entre plusieurs règles.
Moult langages de programmation back-end permettent d'effectuer ces mêmes redirections en renvoyant l'en-tête HTTP correspondant. En PHP c'est très simple grâce à la fonction header()
qu'il faut appeler avant tout autre envoi de contenu (par exemple pas d'appel à echo
auparavant).
Redirection 301 :
<?php
// Redirection 301 basique
header("Location: https://exemple.com/nouvelle-page", true, 301);
exit;
?>
Redirection 302 :
<?php
// Redirection 302 (par défaut)
header("Location: https://exemple.com/page-temporaire");
exit;
// Explicitement 302
header("Location: https://exemple.com/page-temporaire", true, 302);
exit;
?>
Configuration Nginx : avec une syntaxe un peu plus "moderne" que le vétéran Apache, cela reste assez lisible et explicite.
server {
# Redirection 301
location /ancienne-page {
return 301 /nouvelle-page;
}
# Redirection 302
location /page-temporaire {
return 302 /autre-page;
}
# Migration HTTPS
if ($scheme != "https") {
return 301 https://$server_name$request_uri;
}
}
â ï¸ Attention : Les redirections JavaScript ne sont pas idéales pour le SEO car elles ne sont pas des redirections HTTP natives, dans ce cas elles ne sont pas du tout interprétées de la même façon par les navigateurs ou les robots d'indexation des moteurs de recherche.
// Redirection simple (équivalent à 302)
window.location.href = '/nouvelle-page';
// Ou
window.location.replace('/nouvelle-page');
Toutes ces redirections ont toujours une signification pour les outils qui exploitent le protocole HTTP, à savoir les robots des moteurs de recherche en particulier. Vous pouvez aussi consulter la documentation Google Search Central à ce sujet.
Avantages :
Précautions :
Caractéristiques SEO :
Bonnes pratiques :
Le cache des navigateurs peut être sensible aux redirections.
Avec une redirection 301 (Permanente), les navigateurs et les moteurs de recherche mettent à jour leur cache pour pointer directement vers la nouvelle URL. Après la première redirection, le navigateur stocke la nouvelle URL et l’utilise directement pour les requêtes suivantes, sans repasser par la redirection. Ce qui peut être gênant pour tester à nouveau cette redirection, la reconfigurer avec une autre adresse, bref, utilisez le mode navigation privée pour ne pas influencer votre cache local.
La nouvelle URL est généralement cachée longtemps, selon les en-têtes Cache-Control
ou Expires
renvoyés par le serveur.
Avec une redirection 302 (Temporaire), l'impact est limité : les navigateurs ne mettent pas à jour leur cache pour la redirection. À chaque visite, le navigateur recontacte le serveur pour vérifier si la redirection est toujours active. La redirection est toujours exécutée, même après plusieurs visites.
Les Chrome DevTools ou Firefox Developer Tools sont vos meilleurs amis. Ouvrez le panneau, et utilisez l'onglet Réseau (ou Network). Cochez l'option Preserve log avant de naviguer pour conserver les traces de chaque requête (sinon elles sont vidées à chaque changement de page ou redirection) et visualiser toutes les étapes avec leurs codes de statut 301 ou 302. Cliquez sur chaque requête pour examiner les en-têtes HTTP en détails.
Sur cette capture on peut constater de multiples redirections successives (qui auraient pu être fusionnées en une seule) :
adsl.free.fr
→ 302 → free.fr
free.fr
→ 301 → www.free.fr
www.free.fr/freebox
→ 301 → www.free.fr/freebox/
www.free.fr/freebox/
et livraison de la pageLe célèbre outil en ligne de commande cURL est très pratique pour analyser les redirections grâce à l'option -L
.
curl -L --max-redirs 10 -v https://exemple.com/page 2>&1 | grep "Location:"
L'option -I
(ou --head
) permet d'envoyer une requête HEAD au serveur, plutôt qu'une requête GET complète ce qui est utile pour vérifier le statut HTTP de la réponse du serveur, sans télécharger le corps de la page (le contenu HTML, les images, etc.).
curl -I https://exemple.com/page
Si on combine, le tout en ajoutant encore -v
pour avoir plus de détails, cela nous permet de suivre les redirections avec curl -L -I -v https://exemple.com/page
Il est fréquent de se mélanger les pinceaux, outre le piège d'utiliser un code 302 au lieu de 301 pour un changement permanent, ce sont des bugs vite repérés et signalés par votre navigateur :
Les chaînes trop longues : en passant par A → B → C → D → E cela ralentit le chargement et rend difficile l'analyse du réseau et des bugs, cela alourdit le back-end "pour rien".
Les boucles de redirection : si votre script ou configuration provoque une boucle infinie A → B → A et ainsi de suite, il n'est plus possible de s'en sortir. En général le navigateur s'arrête au bout de 20 redirections et renvoie le code ERR_TOO_MANY_REDIRECTS
pour éviter de saturer le réseau, la machine ou les attaques par déni de service.
Avant | Après |
---|---|
â Vérifier si la redirection est vraiment nécessaire | â Tester avec différents outils |
â Choisir le bon type (301 vs 302) | â
Vérifier les logs du serveur (par exemple dans /var/log/apache2 ) |
â Tester sur un environnement de développement | â Surveiller via des outils externes tels que Google Search Console |
â Vérifier l'absence de boucles |
Les redirections HTTP 301 et 302 sont présentes depuis bien longtemps dans le protocole HTTP et restent très pertinentes, utilisées correctement : elles améliorent l'expérience utilisateur et préservent le référencement de votre site. Désormais vous savez tout sur le sujet et faire le choix entre une redirection permanente ou temporaire.
L'attribut contenteditable
en HTML permet de rendre des éléments éditables directement dans le navigateur, en quelque sorte un super-textarea qui permet la mise en forme dans tout élément HTML parce qu'on peut y placer ce qu'on veut... Ce qui est justement le problème de sa valeur par défaut true
: cette totale liberté permet l'insertion de balises <script>
, ce qui peut créer des failles de sécurité et des comportements indésirables.
â¡ï¸ C'est là qu'intervient contenteditable="plaintext-only"
, une valeur moins connue - car récente - mais extrêmement utile, car contrairement à contenteditable="true"
ou contenteditable
qui accepte tout code HTML, contenteditable="plaintext-only"
esquive automatiquement tout formatage et ne conserve que le texte brut.
contenteditable="true"
ou contenteditable
On obtient le comportement par défaut :
contenteditable="plaintext-only"
ðChamp de titre ou nom, dans un CMS, enregistré ensuite en asynchrone par JavaScript / fetch.
<h1 contenteditable="plaintext-only" class="editable-title">
Cliquez pour modifier le titre
</h1>
Zone de commentaire :
<div contenteditable="plaintext-only" class="comment-input" placeholder="Votre commentaire...">
</div>
Étiquettes ou tags :
<span contenteditable="plaintext-only" class="tag">
Tag modifiable
</span>
Pour récupérer le contenu, avec plaintext-only
, les propriétés textContent
et innerHTML
donnent le même résultat.
const element = document.querySelector('[contenteditable="plaintext-only"]');
const content = element.textContent; // Recommandé
const htmlContent = element.innerHTML; // Sera identique à textContent
contenteditable="plaintext-only"
est bien supporté par les navigateurs actuels, pour plus de détails consultez le tableau de support Caniuse.
Même avec plaintext-only
, il reste obligatoire de toujours valider ce que vous recevez côté serveur car rien n'empêchera quelqu'un d'aller vite désactiver cet attribut ou modifier son comportement, voire de forger une simple requête HTTP pour passer outre. Par exemple en PHP on peut prévoir :
$userInput = trim($_POST['content']);
$cleanInput = htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8');
<br>
sont convertis en retours à la ligne simples&
devient &