Entretien avec Valeria Malacasa
Valeria Malacasa est une web designer et designer UX/UI de Turin.
Depuis 2016, elle conçoit et développe des sites web et des interfaces web, tant pour des marques privées que pour des organismes de la Publique Administration italienne.
En 2026, elle a créé la newsletter Switch sur LinkedIn, à travers laquelle elle partage des approfondissements sur l'accessibilité web, l'inclusivité, le design web, l'usabilité web et l'optimisation des performances web. Elle est l'auteure du livre "Switch on - Accessibilité".
1. Valeria, commençons simplement : pourquoi un livre sur l'accessibilité web justement maintenant ? Y a-t-il eu un épisode, un projet ou une frustration professionnelle qui t'a fait dire : "Ok, il faut mettre cela en ordre" ?
Ici (sur LinkedIn ndr.), j'ai commencé à publier des contenus éducatifs et de vulgarisation sur l'accessibilité web au début de 2026, et j'ai immédiatement reçu un bon retour.
En particulier, un de mes abonnés a commenté ainsi un post sur le skip link : “J'apprends plus de toi que dans de nombreux cours que j'ai suivis”. D'autres m'ont écrit, en privé ou non, que grâce à mon langage simple, je parvenais à expliquer des concepts même complexes sans les rendre ennuyeux.
Cela m'a donné l'élan dont j'avais besoin !
J'ai compris que j'avais des choses à dire et qu'il fallait un outil qui rapproche les professionnels de l'accessibilité web, dans un format "entrée de gamme", qui aille droit au but.
2. Switch On : Accessibilité est ton premier livre. Qu'est-ce qui t'a poussée à transformer compétences, exemples et check-lists en un guide structuré ?
Je travaille sur des projets de la Publique Administration depuis début 2022, et au cours de ces années, j'ai compris qu'il existe encore de nombreux préjugés et barrières concernant l'accessibilité web, qui découragent les designers et les développeurs.
Le premier d'entre eux : l'idée que l'accessibilité web soit difficile, tant à étudier qu'à appliquer.
En réalité, beaucoup des meilleures pratiques sont simples, plus que ce que l'on pense !
Mais si pour étudier l'accessibilité on part de la documentation officielle du W3C ou d'un manuel de 350 pages sur les normes, l'histoire de l'accessibilité numérique et l'explication complète des WCAG (les normes internationales de l'accessibilité web), il est clair que l'on peut se décourager et abandonner le sujet, déléguant à des figures spécialisées.
C'est surtout pour cela que j'ai voulu créer un guide pratique, bien structuré, agile et focalisé uniquement sur ce qui est réellement nécessaire dans le travail quotidien de web designer et de web developer, car une fois arrivés à la dernière page, les lecteurs pensent : “Alors, ce n'est pas si compliqué de faire un site web accessible !”.
3. À qui as-tu pensé en l'écrivant : designers, développeurs, agences, freelances, clients finaux ? Qui voudrais-tu qu'il garde ouvert à côté de l'écran pendant qu'il travaille ?
Principalement, il est écrit pour les web designers, ou en tout cas pour ceux qui s'occupent de la conception graphique et du développement de sites web.
J'ai écrit le livre en apportant mon expérience de web designer et j'ai suivi exactement le processus de réalisation de mes projets, en partant d'un aperçu sur l'accessibilité, pour ensuite arriver au projet graphique, au développement, à la création de contenus via un langage inclusif, et enfin aux tests.
4. Beaucoup traitent l'accessibilité comme une vérification finale, presque une révision à faire lorsque le site est déjà terminé. Pourquoi penses-tu que c'est une erreur ?
L'idée qu'un produit ou service doit pouvoir être utilisé par toutes les personnes, indépendamment de leurs conditions physiques et mentales, de la présence ou non de handicaps, doit entrer dans le projet dès le début.
La traiter uniquement à la fin du projet entraîne principalement deux inconvénients :
- niveau d'accessibilité faible ou inexistant ;
- investissement plus important pour la révision.
Un exemple concret : les rampes des trottoirs.
Si un trottoir n'a pas de rampe permettant un passage facile aux personnes en fauteuil roulant, aux personnes à mobilité réduite ou à celles qui poussent une poussette, que se passe-t-il ? Les deux scénarios, en général, sont :
- dans le pire des cas, le trottoir reste ainsi, et avec lui la barrière architecturale ;
- dans le meilleur des cas, le trottoir est cassé et la rampe est ajoutée, avec un coût pour la collectivité en termes financiers et de délais.
Si, en revanche, ce trottoir avait été réalisé dès le départ avec les rampes adéquates, le problème ne se serait pas posé, les délais et les coûts de réalisation auraient été pratiquement identiques et la barrière architecturale ne se serait jamais présentée.
J'ai un peu simplifié, mais le concept vaut aussi pour l'accessibilité web.
Revenir sur le code et la graphisme d'une interface peut coûter des semaines de développement, avec des coûts qui seraient pratiquement annulés si l'accessibilité était incluse dès le départ.
Souvent, ce sont précisément ces coûts de reprise qui bloquent, et les interfaces restent non accessibles.
5. Quel est le faux mythe le plus difficile à déconstruire sur l'accessibilité web ? Celui que tu entends répéter le plus souvent et qui te donne envie de lancer un validateur WCAG par la fenêtre.
Il y en a plusieurs et la réaction est plus ou moins celle-là !
Probablement, celui qui me dérange le plus - et que j'ai également inclus dans le livre - est que l'accessibilité web concerne seulement quelques personnes.
Il y a deux aspects de ce faux mythe qui doivent être déconstruits.
Tout d'abord, l'accessibilité web concerne potentiellement tout le monde, pas seulement les personnes en situation de handicap. Pense au contraste des couleurs : il est utile pour les personnes malvoyantes, mais aussi pour ceux qui utilisent leur téléphone au soleil ou avec une luminosité réduite. Un peu comme la rampe du trottoir dont je parlais plus tôt : elle est essentielle pour les personnes en fauteuil roulant, mais utile aussi pour moi qui pousse mon fils dans une poussette ou pour une personne qui utilise temporairement des béquilles.
Deuxièmement, il y a une raison plus éthique pour laquelle ce préjugé n'a pas de sens.
Si les personnes qui peuvent bénéficier d'un site web accessible étaient effectivement peu nombreuses, serait-ce une bonne raison de les exclure ? Pourquoi une personne aveugle ou sourde devrait-elle "valoir moins" que cent personnes non aveugles et non sourdes ? Et si cette unique personne en situation de handicap était justement celle qui a besoin de demander un devis ou de demander une démo du produit vendu ?
Un autre avantage non négligeable, dans le design web, est qu'un code HTML propre et sémantique est utile à la fois pour les lecteurs d'écran et pour les bots des moteurs de recherche et les IA, ce qui a des répercussions positives sur le SEO et la GEO.
6. Dans le livre, tu parles de design accessible, de contraste chromatique, de HTML sémantique, d'ARIA, de lecteurs d'écran et de navigation au clavier. Par où devrait commencer celui qui se sent aujourd'hui devant un labyrinthe ?
Je ne vais pas te mentir : les règles d'accessibilité sont nombreuses, certaines plus simples, d'autres moins, et toutes les bonnes pratiques ne sont pas codifiées dans les WCAG. L'accessibilité web passe par divers aspects, visuels et non, tous importants de la même manière.
La bonne nouvelle, c'est qu'il n'est pas nécessaire de tous les connaître !
Le design est le premier pas, car s'il y a des problèmes d'accessibilité, ceux-ci se présenteront également lors du développement, mais on ne peut pas nier que l'utilisation d'un code HTML sémantique est à la base d'une interface accessible.
C'est pourquoi mon livre est un bon point de départ, car il identifie uniquement les règles essentielles et permet d'avoir un aperçu sur le sujet.
7. Si vous deviez indiquer trois erreurs courantes qui rendent un site moins accessible, lesquelles choisiriez-vous ? Celles qui sont petites, quotidiennes, apparemment innocentes, mais capables de fermer des portes au visage des utilisateurs.
Ce sont les erreurs que je vois le plus souvent - et, d'ailleurs, celles qui se résolvent aussi plus facilement - :
- rapport de contraste entre le texte et l'arrière-plan insuffisant ;
- utilisation de la balise HTML <button> pour les liens et de <a> pour les boutons ;
- absence de lien de saut au début de la page.
Ce sont trois erreurs “petites”, simples à résoudre, mais qui pour une personne utilisant un lecteur d'écran, ayant des déficiences visuelles ou des difficultés à utiliser une souris et un trackpad, rendent la navigation complexe et frustrante.
8. Quel poids a l'accessibilité dans la qualité globale d'un site ? En d'autres termes : un site accessible est-il “juste” plus inclusif, ou est-il aussi mieux conçu ?
Pour moi, l'accessibilité a autant de poids que tous les autres aspects qualitatifs, de l'esthétique à l'optimisation des conversions.
De nombreuses bonnes pratiques d'accessibilité ont des répercussions importantes sur le SEO, l'utilisabilité et les conversions.
Un site web très beau, mais non accessible, aura probablement un HTML sale et non sémantique, des contenus qui changent via JavaScript, des éléments visuels complexes à percevoir et à utiliser, et cela n'est pas un mal seulement pour les personnes en situation de handicap : c'est un mal pour tous les visiteurs et une perte potentielle d'opportunités commerciales et de branding pour ceux qui ont investi de l'argent dans ce site web.
Un site accessible apporte des bénéfices à quiconque le visite, et par conséquent aussi à la marque qui souhaite obtenir des résultats concrets avec ce site.
9. Que peuvent concrètement faire les agences et les équipes pour intégrer l'accessibilité dans le processus sans la transformer en une montagne bureaucratique ?
Tout d'abord, il faut comprendre ce qu'est l'accessibilité web et pourquoi elle est importante.
C'est une partie incontournable de notre travail et c'est la raison pour laquelle j'ai inclus ce sujet dans la première partie de mon livre.
Il faut abandonner tout préjugé, comprendre sur quels principes repose l'accessibilité et quels bénéfices elle apporte, non seulement aux visiteurs d'un site web mais à tous les parties prenantes.
Ensuite, on peut partir de mon livre, ou étudier des manuels plus complets, mais indubitablement à un certain moment, il faut ouvrir le site web du W3C et étudier les WCAG, au moins celles de niveau A et AA qui s'appliquent au projet réalisé.
Il y a ensuite d'autres aspects réglementaires à approfondir, comme la déclaration d'accessibilité et le mécanisme de retour d'information. Ici, aborder la bureaucratie est inévitable si le site web est soumis aux obligations prévues par la Loi Stanca ou par le récent European Accessibility Act.
10. Si une personne terminait votre livre et décidait de changer une seule chose dans la façon dont elle conçoit ou développe des sites web, laquelle aimeriez-vous qu'elle soit ?
J'aimerais que cette personne apprenne à toujours se poser des questions, ce qui est d'ailleurs la raison pour laquelle j'ai créé le projet Switch.
Si la personne qui a lu le livre commençait un nouveau site web, et au moment d'écrire le code HTML du logo en haut à gauche se demandait : “Un instant, mais si je l'écris de cette manière, le lecteur d'écran le lira-t-il correctement ?” alors j'aurai certainement atteint mon objectif !
Vous pouvez mieux connaître Valeria sur LinkedIn : https://www.linkedin.com/in/valeriamalacasa/ ou sur son site web : valeriamalacasa.it
Votre projet est bloqué par une limite technique ?
Réserver 15 minutes