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.
[^] # Re: Manquer le sujet?
Posté par Alcyone . En réponse au lien Why Don’t Developers Take Accessibility Seriously?. É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