Dans le Web, ce qui est triste, c'est que c'est plutôt bien accessible par défaut si on prend le temps de respecter les notions HTML de base (c'est un coup à prendre peut-être, mais ça ne prend pas tellement longtemps au quotidien au final).
Sauf que j'ai l'impression que souvent, dans le monde du développement frontend, on se bat en permanence contre CSS et HTML, à coup de CSS resets et de soupes de div. On ne comprend pas bien pourquoi on devrait utiliser des balises p pour faire des paragraphes quand ça marche avec des div et des br. Ces foutues balises p ajoutent des marges pénibles à gérer, autant partir d'un div qu'on contrôle totalement. Les table c'est mal donc on vire... et on remplace ça par des div imbriquées avec des classes bootstrap pour définir des lignes et des colonnes (non, je ne parle pas des tables pour faire de la présentation, mais bien pour afficher des données / entrées). les balises ul et li, pareil, ça ajoute des puces et des marges disgracieuses, avec des div c'est plus simple...
On ne pense pas en termes de sens et de structure HTML, mais en terme de comment ça doit s'afficher.
Mais en fait, quand on a une bonne structure HTML, c'est vite plus accessible sans effort (le navigateur sait faire automatiquement plein de chose avec ce qu'on lui donne), et on peut obtenir un affichage cohérent et logique probablement plus facilement Ensuite, c'est facile de rendre ça joli sans faire trop d'effort. Mais il faut le faire dans ce sens. Cependant, quand on écrit une application, on n'a pas forcément l'idée que c'est encore du HTML et tout ce qui va avec derrière, y compris sa sémantique... et c'est bien dommage. L'envie d'avoir son branding / une identité graphique bien particulière dans son UI n'aide pas toujours.
Il y a aussi le fait qu'on réinvente très vite les composants de base dans chaque projet, au lieu d'avoir une belle bibliothèque de composante toute faite et bien rodée comme on pourrait trouver dans les toolkits graphiques pour bureau comme Qt, GTK ou Cocoa, et où l'accessibilité vient par défaut. Ou on importe des bibliothèques React un peu random avec des qualité inégales et sans garanties.
Un jeu de composants tout prêt avec une accessibilité rôdée permettrait de régler un certain nombre de problèmes...
C'est comme les habitations, ce qui est plus accessible est souvent aussi plus facile ou agréable à utiliser pour tout le monde, mais ce n'est pas nécessairement facile de s'en rendre compte.
Mon message c'est : si on ne conçoit pas avec les outils qu'on utilise mais contre eux, oui, "ajouter" l'accessibilité c'est coûteux, mais si on embrasse les technos conçues pour ça, ça se passe déjà beaucoup mieux.
J'espère que je me trompe et que j'ai une vue trop réduite du monde du développement frontend.
Tout cela étant dit, bien sûr, tant que ce n'est pas testé (avec des lecteurs d'écrans, etc), on ne peut pas être sûr que ça fonctionne bien donc il y a des coûts dont on ne peut pas se passer si on veut être sûr d'être accessible.
[^] # Re: Manquer le sujet?
Posté par raphj (site web personnel) . En réponse au lien Why Don’t Developers Take Accessibility Seriously?. Évalué à 10.
Entièrement d'accord. Et j'aimerais compléter.
Dans le Web, ce qui est triste, c'est que c'est plutôt bien accessible par défaut si on prend le temps de respecter les notions HTML de base (c'est un coup à prendre peut-être, mais ça ne prend pas tellement longtemps au quotidien au final).
Sauf que j'ai l'impression que souvent, dans le monde du développement frontend, on se bat en permanence contre CSS et HTML, à coup de CSS resets et de soupes de div. On ne comprend pas bien pourquoi on devrait utiliser des balises p pour faire des paragraphes quand ça marche avec des div et des br. Ces foutues balises p ajoutent des marges pénibles à gérer, autant partir d'un div qu'on contrôle totalement. Les table c'est mal donc on vire... et on remplace ça par des div imbriquées avec des classes bootstrap pour définir des lignes et des colonnes (non, je ne parle pas des tables pour faire de la présentation, mais bien pour afficher des données / entrées). les balises ul et li, pareil, ça ajoute des puces et des marges disgracieuses, avec des div c'est plus simple...
On ne pense pas en termes de sens et de structure HTML, mais en terme de comment ça doit s'afficher.
Mais en fait, quand on a une bonne structure HTML, c'est vite plus accessible sans effort (le navigateur sait faire automatiquement plein de chose avec ce qu'on lui donne), et on peut obtenir un affichage cohérent et logique probablement plus facilement Ensuite, c'est facile de rendre ça joli sans faire trop d'effort. Mais il faut le faire dans ce sens. Cependant, quand on écrit une application, on n'a pas forcément l'idée que c'est encore du HTML et tout ce qui va avec derrière, y compris sa sémantique... et c'est bien dommage. L'envie d'avoir son branding / une identité graphique bien particulière dans son UI n'aide pas toujours.
Il y a aussi le fait qu'on réinvente très vite les composants de base dans chaque projet, au lieu d'avoir une belle bibliothèque de composante toute faite et bien rodée comme on pourrait trouver dans les toolkits graphiques pour bureau comme Qt, GTK ou Cocoa, et où l'accessibilité vient par défaut. Ou on importe des bibliothèques React un peu random avec des qualité inégales et sans garanties.
Un jeu de composants tout prêt avec une accessibilité rôdée permettrait de régler un certain nombre de problèmes...
C'est comme les habitations, ce qui est plus accessible est souvent aussi plus facile ou agréable à utiliser pour tout le monde, mais ce n'est pas nécessairement facile de s'en rendre compte.
Mon message c'est : si on ne conçoit pas avec les outils qu'on utilise mais contre eux, oui, "ajouter" l'accessibilité c'est coûteux, mais si on embrasse les technos conçues pour ça, ça se passe déjà beaucoup mieux.
J'espère que je me trompe et que j'ai une vue trop réduite du monde du développement frontend.
Tout cela étant dit, bien sûr, tant que ce n'est pas testé (avec des lecteurs d'écrans, etc), on ne peut pas être sûr que ça fonctionne bien donc il y a des coûts dont on ne peut pas se passer si on veut être sûr d'être accessible.