Soit j'ai mal compris ce que l'auteur veut dire, soit il oublie le principal.
Tous les conseils qu'il donne dans le deuxième partie semblent bien… Sauf quand le temps c'est de l'argent. Et il ne répond pas à comment rentabiliser la chose (oui 1% de personnes de perdues c'est important si le nombre de visiteurs potentiels est gros, mais si le gain est 1% pour 10% d'investissement en plus, qui à part les altruistes vont faire cette dépense?).
Ce n'est pas pour dire de ne pas faire, juste que la réponse à la question est simple et ne nécessite pas vraiment un long billet : parce que ça coûte plus que ça ne rapporte, même avec de "bons" outils actuellement disponible, selon ma connaissance du sujet. Et qu'il faut indiquer comment réduire ce coût si on veut sortir des sites accessibles uniquement quand quelqu'un est prêt à perdre du temps/argent par principe qu'il faut être accessible. Dire "their artistic vision needs to be usable by everyone." ne rend pas cette phrase universelle : pourquoi il y aurait ce besoin, d'un point de vue individuel du développeur/designer pas sensible à ce sujet et non forcé par de pénalités légales si il ne fait pas?
Je suis preneur de contre-exemples, démontrant comment ça a été rentable chez quelqu'un qui fait des sites généralistes d'avoir un site accessible.
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.
J'ai l'impression que la personne ne prend pas le temps d'aborder le sujet en profondeur, peut-être le sait-elle déjà trop, mais le fait d'une certaine manière en parlant de l'existant déjà inaccessible.
Rendre accessible quelque chose qui ne l'est pas est généralement assez coûteux. Jusque là, rien de nouveau mais la raison est bien moins comprise : faire un site accessible, c'est surtout le concevoir accessible, ce n'est pas une histoire d'outils à utiliser.
Un site déjà inaccessible, selon à quel point sa conception est ancrée dans de mauvaises pratiques (raphj indique combien il est courant de ne pas suivre la sémantique du HTML par exemple) peut-être entièrement à refaire.
A l'opposé de ça, concevoir un site accessible dès la base n'est globalement pas vraiment plus coûteux.
Seulement, il faut être formé.
Le problème reste que l'accessibilité n'est pas réellement présente en formation initiale, ni en formation continue, ni très présente tout court en fait alors que concevoir accessible revient à respecter une norme, l'accessibilité n'est pas une feature.
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.
raphj
On peut généraliser sans parler d'accessibilité en parlant tout simplement du site en fait : "tant que ce n'est pas testé, on ne peut pas être sûr que ça fonctionne".
Gagner en confiance sur le fonctionnement est un des objets du test logiciel de façon générale, l'une de ses raisons d'être.
L'accessibilité n'est pas une feature supplémentaire et doit faire parti des tests, le monde du test n'est pas en reste question défaut de formation sur le sujet comparé au monde du développement (pour ainsi, les formations initiales en test logiciel en France…).
Pour finir de boucler, de même qu'ajouter l'accessibilité à l'existant non accessible est coûteux, le test logiciel sur un site non accessible en tenant compte de l'accessibilité l'est également.
En revanche quand le site est conçu de façon accessible, ça ne change pas grand chose pour le testeur et l'on remonte des rapports d'anomalie sur l'accessibilité au même titre que le reste pour des soucis dont la rareté s'assimile à la qualité de développement global dudit site.
Je pense sincèrement que faire de l'accessibilité une feature supplémentaire est un des plus gros écueil de conception dans lesquels on peut tomber (pas très de celui de penser que des outils font l'accessibilité d'un site).
Il me semble au final que la personne qui écrit de l'article est consciente de tout cela et propose pour cela de rattraper ce retard de formation et termine par quelques exemples, domaines assez simples qui changent l'approche de conception et font déjà une très grand partie de l'accessibilité d'un site.
Bon, Alcyone et raphj ont répondu sur le plus important : l'accessibilité coûte quand c'est pris en compte après coup. (il y a un coup certain et non négligeable à désamianter un bâtiment ou le rendre moins énergivore, alors que pris en compte dès la conception c'est plus la même chose.)
Mais il y a un biais non abordé illustré par la parenthèse : « comment rentabiliser la chose (oui 1% de personnes de perdues c'est important si le nombre de visiteurs potentiels est gros, mais si le gain est 1% pour 10% d'investissement en plus, qui à part les altruistes vont faire cette dépense?) » Malheureusement, même Wikipédia enfonce ce lieu commun en commençant par résumer l'accessibilité à « la problématique de l'accès aux contenus et services web par les personnes handicapées (déficients visuels, sourds, malentendants, etc.) » Cependant, heureusement, cette phrase d'ouverture se poursuit pas « et plus généralement par tous les utilisateurs, quels que soient leurs dispositifs d’accès (mobile, tablette, etc.) ou leurs conditions d’environnement (niveau sonore, éclairement, etc.). Les pratiques d'accessibilité cherchent à réduire ou supprimer les obstacles qui empêchent les utilisateurs d'accéder à des contenus ou d'interagir avec des services. » À partir de là, on comprend qu'on ne cible pas 1% de handicapés mais qu'il s'agit que l'information qu'on veut délivrer soit accessible à 100% des internautes. Le paragraphe suivant laisse entrevoir qu'il est plus question de démarche (et de bonnes pratiques et d'état d'esprit) que d'investissement financier : « L'accessibilité est définie par des normes techniques établies par la Web Accessibility Initiative (WAI) du World Wide Web Consortium (W3C). Elle nécessite un traitement tout au long du cycle de vie d'un site web, par l'ensemble de ses acteurs, via des méthodes d'applications, des référentiels métiers et une démarche de suivi. » Plus loin (Champ de l'accessibilité) on voit qu'on croit traiter pour 1% de non-voyants et que finalement on touche près de 20% de la population : « L'accessibilité du web signifie que les personnes handicapées peuvent l'utiliser. Plus spécifiquement, elle signifie que ces gens peuvent percevoir, comprendre, naviguer, interagir avec le web, et y contribuer. L'accessibilité du web bénéficie également à d'autres, notamment les personnes âgées ayant des capacités diminuées dues au vieillissement. »
C'est pourquoi je rejoins l'auteur, qui en fait est en train de souligner le fait que les dits pro du web ne soient pas formés/sensibilisés à l'accessibilité, qu'il faut s'intéresser au sujet (en côtoyant et en écoutant les personnes lésées.) On ne peut pas adresser correctement/sérieusement un sujet si l'on ne le comprend pas, et c'est le cas de l'accessibilité qui justement touche tout le monde à un moment ou un autre sur une certaine durée. Lectures complémentaires https://www.lesechos.fr/idees-debats/leadership-management/handicap-le-chemin-de-croix-existe-aussi-sur-le-web-1246452 et https://www.talenteo.fr/accessibilite-numerique-sites-web/
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Why Don’t Developers Take Accessibility Seriously?
… sur une site dont la mise en page est codée en dur sur une largeur de 600px, indépendant de la taille de la police par défaut dans le navigateur. La preuve par l‘exemple ?
On dit que ce sont les cordonniers qui sont les plus mal chaussés :-D
Cependant, je viens d'essayer avec tablettes et smartphones de diverses tailles : le contenu est bien adapté et les 600px ne semblent s'appliquer qu'aux ordis (pour lesquels le minimum attendu en mode graphique est 800*600 justement ?)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
le contenu est bien adapté et les 600px ne semblent s'appliquer qu'aux ordis (pour lesquels le minimum attendu en mode graphique est 800*600 justement ?)
Si on affiche le navigateur en plein écran, oui. Mais ce n'est pas toujours le cas, tu peux le faire afficher que sur la moitié, un quart ou n'importe quelle dimension grâce à ton gestionnaire de fenêtre préféré 🙂
Par contre, ce n'est pas évident d'être utilisable / lisible pour n'importe quelle dimension…
# Manquer le sujet?
Posté par Zenitram (site web personnel) . Évalué à 6.
Soit j'ai mal compris ce que l'auteur veut dire, soit il oublie le principal.
Tous les conseils qu'il donne dans le deuxième partie semblent bien… Sauf quand le temps c'est de l'argent. Et il ne répond pas à comment rentabiliser la chose (oui 1% de personnes de perdues c'est important si le nombre de visiteurs potentiels est gros, mais si le gain est 1% pour 10% d'investissement en plus, qui à part les altruistes vont faire cette dépense?).
Ce n'est pas pour dire de ne pas faire, juste que la réponse à la question est simple et ne nécessite pas vraiment un long billet : parce que ça coûte plus que ça ne rapporte, même avec de "bons" outils actuellement disponible, selon ma connaissance du sujet. Et qu'il faut indiquer comment réduire ce coût si on veut sortir des sites accessibles uniquement quand quelqu'un est prêt à perdre du temps/argent par principe qu'il faut être accessible. Dire "their artistic vision needs to be usable by everyone." ne rend pas cette phrase universelle : pourquoi il y aurait ce besoin, d'un point de vue individuel du développeur/designer pas sensible à ce sujet et non forcé par de pénalités légales si il ne fait pas?
Je suis preneur de contre-exemples, démontrant comment ça a été rentable chez quelqu'un qui fait des sites généralistes d'avoir un site accessible.
[^] # Re: Manquer le sujet?
Posté par raphj . É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.
[^] # Re: Manquer le sujet?
Posté par Alcyone . Évalué à 4.
J'ai l'impression que la personne ne prend pas le temps d'aborder le sujet en profondeur, peut-être le sait-elle déjà trop, mais le fait d'une certaine manière en parlant de l'existant déjà inaccessible.
Rendre accessible quelque chose qui ne l'est pas est généralement assez coûteux. Jusque là, rien de nouveau mais la raison est bien moins comprise : faire un site accessible, c'est surtout le concevoir accessible, ce n'est pas une histoire d'outils à utiliser.
Un site déjà inaccessible, selon à quel point sa conception est ancrée dans de mauvaises pratiques (raphj indique combien il est courant de ne pas suivre la sémantique du HTML par exemple) peut-être entièrement à refaire.
A l'opposé de ça, concevoir un site accessible dès la base n'est globalement pas vraiment plus coûteux.
Seulement, il faut être formé.
Le problème reste que l'accessibilité n'est pas réellement présente en formation initiale, ni en formation continue, ni très présente tout court en fait alors que concevoir accessible revient à respecter une norme, l'accessibilité n'est pas une feature.
On peut généraliser sans parler d'accessibilité en parlant tout simplement du site en fait : "tant que ce n'est pas testé, on ne peut pas être sûr que ça fonctionne".
Gagner en confiance sur le fonctionnement est un des objets du test logiciel de façon générale, l'une de ses raisons d'être.
L'accessibilité n'est pas une feature supplémentaire et doit faire parti des tests, le monde du test n'est pas en reste question défaut de formation sur le sujet comparé au monde du développement (pour ainsi, les formations initiales en test logiciel en France…).
Pour finir de boucler, de même qu'ajouter l'accessibilité à l'existant non accessible est coûteux, le test logiciel sur un site non accessible en tenant compte de l'accessibilité l'est également.
En revanche quand le site est conçu de façon accessible, ça ne change pas grand chose pour le testeur et l'on remonte des rapports d'anomalie sur l'accessibilité au même titre que le reste pour des soucis dont la rareté s'assimile à la qualité de développement global dudit site.
Je pense sincèrement que faire de l'accessibilité une feature supplémentaire est un des plus gros écueil de conception dans lesquels on peut tomber (pas très de celui de penser que des outils font l'accessibilité d'un site).
Il me semble au final que la personne qui écrit de l'article est consciente de tout cela et propose pour cela de rattraper ce retard de formation et termine par quelques exemples, domaines assez simples qui changent l'approche de conception et font déjà une très grand partie de l'accessibilité d'un site.
Alcyone
[^] # Re: Manquer le sujet?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Bon, Alcyone et raphj ont répondu sur le plus important : l'accessibilité coûte quand c'est pris en compte après coup. (il y a un coup certain et non négligeable à désamianter un bâtiment ou le rendre moins énergivore, alors que pris en compte dès la conception c'est plus la même chose.)
Mais il y a un biais non abordé illustré par la parenthèse : « comment rentabiliser la chose (oui 1% de personnes de perdues c'est important si le nombre de visiteurs potentiels est gros, mais si le gain est 1% pour 10% d'investissement en plus, qui à part les altruistes vont faire cette dépense?) » Malheureusement, même Wikipédia enfonce ce lieu commun en commençant par résumer l'accessibilité à « la problématique de l'accès aux contenus et services web par les personnes handicapées (déficients visuels, sourds, malentendants, etc.) » Cependant, heureusement, cette phrase d'ouverture se poursuit pas « et plus généralement par tous les utilisateurs, quels que soient leurs dispositifs d’accès (mobile, tablette, etc.) ou leurs conditions d’environnement (niveau sonore, éclairement, etc.). Les pratiques d'accessibilité cherchent à réduire ou supprimer les obstacles qui empêchent les utilisateurs d'accéder à des contenus ou d'interagir avec des services. » À partir de là, on comprend qu'on ne cible pas 1% de handicapés mais qu'il s'agit que l'information qu'on veut délivrer soit accessible à 100% des internautes. Le paragraphe suivant laisse entrevoir qu'il est plus question de démarche (et de bonnes pratiques et d'état d'esprit) que d'investissement financier : « L'accessibilité est définie par des normes techniques établies par la Web Accessibility Initiative (WAI) du World Wide Web Consortium (W3C). Elle nécessite un traitement tout au long du cycle de vie d'un site web, par l'ensemble de ses acteurs, via des méthodes d'applications, des référentiels métiers et une démarche de suivi. » Plus loin (Champ de l'accessibilité) on voit qu'on croit traiter pour 1% de non-voyants et que finalement on touche près de 20% de la population : « L'accessibilité du web signifie que les personnes handicapées peuvent l'utiliser. Plus spécifiquement, elle signifie que ces gens peuvent percevoir, comprendre, naviguer, interagir avec le web, et y contribuer. L'accessibilité du web bénéficie également à d'autres, notamment les personnes âgées ayant des capacités diminuées dues au vieillissement. »
C'est pourquoi je rejoins l'auteur, qui en fait est en train de souligner le fait que les dits pro du web ne soient pas formés/sensibilisés à l'accessibilité, qu'il faut s'intéresser au sujet (en côtoyant et en écoutant les personnes lésées.) On ne peut pas adresser correctement/sérieusement un sujet si l'on ne le comprend pas, et c'est le cas de l'accessibilité qui justement touche tout le monde à un moment ou un autre sur une certaine durée. Lectures complémentaires https://www.lesechos.fr/idees-debats/leadership-management/handicap-le-chemin-de-croix-existe-aussi-sur-le-web-1246452 et https://www.talenteo.fr/accessibilite-numerique-sites-web/
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Faites ce que j’écris, pas ce que je code
Posté par jyes . Évalué à 7.
… sur une site dont la mise en page est codée en dur sur une largeur de 600px, indépendant de la taille de la police par défaut dans le navigateur. La preuve par l‘exemple ?
[^] # Re: Faites ce que j’écris, pas ce que je code
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
On dit que ce sont les cordonniers qui sont les plus mal chaussés :-D
Cependant, je viens d'essayer avec tablettes et smartphones de diverses tailles : le contenu est bien adapté et les 600px ne semblent s'appliquer qu'aux ordis (pour lesquels le minimum attendu en mode graphique est
800*600justement ?)“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Faites ce que j’écris, pas ce que je code
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
Si on affiche le navigateur en plein écran, oui. Mais ce n'est pas toujours le cas, tu peux le faire afficher que sur la moitié, un quart ou n'importe quelle dimension grâce à ton gestionnaire de fenêtre préféré 🙂
Par contre, ce n'est pas évident d'être utilisable / lisible pour n'importe quelle dimension…
# indexation... pertinence
Posté par BAud (site web personnel) . Évalué à 3.
un site bien fait en HTML a plus de chance d'être lisible par les moteurs de recherche
comme indiqué plus haut en commentaire, vouloir un rendu précis revient à confondre le fonds et la forme, et ipso facto le rendre moins visible :/
ce n'est pourtant pas très compliqué de le faire bien dès le début :
et ça fait longtemps que c'est documenté… après, ya moyen de faire plus compliqué (mais àmha ça va être plus cher :p)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.