L'accessibilite web n'est pas un sujet tres present dans les formations au developpement. On apprend le HTML, le CSS, le JavaScript, les frameworks. L'accessibilite apparait parfois comme une mention en passant, un critere de qualite parmi d'autres. C'est en lisant les WCAG par curiosite que j'ai realise a quel point c'etait un angle mort dans ma pratique.
Les Web Content Accessibility Guidelines sont le standard international pour l'accessibilite des contenus web. Elles sont organisees autour de quatre principes : perceptible, utilisable, comprehensible, robuste. En les lisant, j'ai eu une serie de prises de conscience sur des choses que je faisais mal sans le savoir.
Le contraste des couleurs, d'abord. J'avais choisi certaines combinaisons pour des raisons esthetiques, sans jamais verifier si elles etaient lisibles pour quelqu'un avec une deficience visuelle. Les WCAG definissent des ratios de contraste minimaux precis. En testant mes propres interfaces, plusieurs ne passaient pas.
La semantique HTML, ensuite. Utiliser des div pour tout au lieu de header, nav, main, article, button : ca fonctionne visuellement, mais ca prive les technologies d'assistance comme les lecteurs d'ecran de toute la structure de la page. Un utilisateur aveugle qui navigue avec un lecteur d'ecran a besoin que le HTML raconte la meme histoire que ce que les autres voient.
Les attributs ARIA m'etaient vaguement familiers, mais je ne les utilisais jamais vraiment. Apres avoir lu les WCAG, j'ai compris leur role : completer le HTML semantique dans les cas ou il ne suffit pas, notamment pour les composants interactifs personnalises comme les modales, les menus deroulants, ou les tooltips.
Ce qui m'a le plus marque dans cette decouverte, c'est que l'accessibilite n'est pas une contrainte supplementaire qu'on ajoute apres coup. C'est une consequence naturelle d'ecrire un bon HTML. Un code semantique, structure et lisible est accessible presque par defaut. L'accessibilite est un indicateur de qualite technique, pas un extra.