Accessibilité - votre démarche

Bonjour,

Si je vous laisse carte blanche (y compris niveau temps de mise en oeuvre) pour faire un site accessible : une application professionnelle assez complexe pour gérer l'activité d'une entreprise, par exemple, avec toutes les technologies dernier cris, un côté intranet et un autre visible de par le monde, quelle démarche adoptez-vous ?

Ce qui m'intéresse est la manière dont vous vous y prenez, les questions que vous me poseriez, les procédés que vous mettez automatiquement en place, l'ordre dans lequel vous faîtes les choses, etc... etc...

Et sans parler délais mais avec le même objectif (-> être au plus accessible), abordez-vous un petit site perso d'une manière différente ?

Bien bah j'espérais un peu plus de réponses... mais non, je ne dois pas être assez précis.

Là où je voulais en venir, c'est l'accessibilité ne commence-t-elle pas par la définition de limites au cahier des charges ?

Vouloir toucher tout le monde me semble utopique à vrai dire et j'ai tendance à penser, qu'avec la complexité de certaines applications, il convient de faire des choix. Par exemple, dès qu'on ajoute un peu de couleurs, on prend le risque de tomber sur une personne qui les visualiserait mal. Si on corrige le tir en changeant ces couleurs, peut-être est-ce un autre qui, à son tour, aura le même problème et répondre aux deux semble alors impossible. Donc, que faire ? Supprimer les couleurs ? Offrir une alternative via un styleswitcher ou un mécanisme de désactivation ? Faire une sélection sur l'auditorat ?

Supprimer les couleurs est peu envisageable, surtout dans le cadre professionnel. Mettre en place un styleswitcher semble... inutile. Celui qui voit mal les couleurs a généralement pris les devants en paramétrant son navigateur pour qu'il réponde à ses besoins. Mettre en place un système de désactivation me semble inutile aussi vu que le navigateur a (la plupart du temps) la possibilité de le faire seul. On pourrait en dire de même pour des effets JS -> la désactivation est possible. Autrement dit, on en revient à la dernière solution : Décider nous même de la personne à qui on va répondre tout en sachant que, moyennant une certaine gêne, l'application reste accessible du fait que le navigateur puisse être paramétré.

Si j'en reviens à la désactivation d'une fonctionnalité JS, ça peut quand même avoir une utilité : ne désactiver qu'une fonctionnalité là où le navigateur aurait tout couper. En d'autres termes, qu'est-ce qui vous semble utile à mettre en place et sur quoi faites-vous l'impasse ?

Dernièrement, je travaille sur une application où Javascript est considéré comme acquis (intranet) et pourtant, je tente de m'arranger pour que tout puisse fonctionner sans. Je n'y suis pas obligé mais, en même temps, je ne peux décemment pas prétendre que tout le monde va pouvoir s'en servir correctement vu que je ne suis pas seulement exposé à des problèmes d'ordre technique. Continuer, malgré tout, à voir ce langage me semble donc préférable.

En fait, ce qui me parait flou, c'est quand offrir une aide (ou alternative) et quand ne pas le faire... d'où ma question : comment procédez-vous ?

Bonjour,

A mon modeste avis, autant le developpeur devrait pouvoir "imposer" un profond respect de la sémantique, de la méthode, navigation clavier, désactivation js etc pour un site public

Autant sur le site privé ( intranet ou application d'entreprise ) l'adéquation de son intervention et de sa méthode avec l'objectif sont selon moi (forcément) définies par le cahier des charges : l'accessibilité est souvent moins prioritaire ou secondaire et les pré-requis permettent de simplifier les interventions et de pouvoir finaliser l'ensemble;
Puis si l'application rencontre un succès relatif dans l'entreprise, les évolutions futures deviennent plus abouties et plus respectueuses...

J'utilise par exemple beaucoup d'applications en ligne "nouvelles" qui ont profondément modifiées ma vie professionnelle : Net-entreprises.fr ( Un million d'inscrits en 2006 ) ou un S.I.RH. en dot net : les deux sont parfaitement inaccessibles et ont Windows et Msie>6 en pré-requis sur de nombreuses fonctionnalités: mais elles ont le mérite d'exister et grâce au succès d'utilisation elles tendront forcément vers la prise en compte de l'accessibilité et de la compatibilité...

Amicalement

Désolé, je n'ai pas l'expérience pour répondre à ce genre de questionnement. Que certains principes d'interopérabilité et d'accessibilité doivent être pris en compte dans le cahier des charges, ça me parait évident si on veut avoir une chance de réaliser un site ou une application accessible.
Pour le détail... je passe la main.

Au sujet de l'exemple choisi avec les couleurs : sauf erreur de ma part, ce n'est pas du ressort du designer de s'adapter à tous les handicaps de vision déficiente des couleurs. Comme tu le soulignes, si un utilisateur a des besoins spécifiques, il pourra utiliser des outils spécifiques ou certaines fonctionnalités de son navigateur.

Il me semble que pour les couleurs, les directives d'accessibilité retiennent deux principes :
- un contraste texte/fond suffisant ;
- ne pas faire reposer l'information sur des couleurs.

Le premier concerne le designer. Le deuxième concerne le designer et le développeur.
(Un peu la flemme de me plonger dans le RGAA là tout de suite, mais on doit probablement retrouver des points de contrôle qui vont bien, et les profils concernés indiqués pour chaque point de contrôle.)

OlivierD, selon ta réponse, c'est "faisons, on fera mieux ensuite".

Lorsqu'on a conscience d'un risque il est à mon avis important de l'anticiper lorsque c'est possible. Certes, dans le cadre professionnel, cela implique un budget plus important.

Il est peut être un "coût" supplémentaire d'aborder le problème à la base, il en est un bien plus grand de rattraper les pertes de temps et parfois d'argent. Le coût devient alors un investissement.

Dans le cas d'un outil interne à une entreprise (intranet ou application spécifique), le groupe est bien évidemment plus restreint que s'il s'agissait de la totalité des internautes de la planète. Quoi qu'il en soit, il subsistera toujours des différences entre les utilisateurs, et entre leur matériel. Il sera difficile pour les responsables de projets d'aller recueillir les impressions de chacun, ou de vérifier et paramétrer leur matériel.

Que des applications en ligne sans prise en compte de l'accessibilité fonctionnent et connaissent un succès important, je le conçois, car une majorité d'utilisateurs a la capacité pour y accéder, certains peut être avec plus de peine.
Je suis par contre sceptique sur l'amélioration future provoquée grâce au succès. On améliore souvent un outil par l'ajout de fonctionnalités supplémentaires, mais on se penche rarement sur ce qui ne nous pose pas de problème (notamment en matière d'accessibilité), ou sur ce qui peut poser d'autres problèmes que ceux que nous connaissons.
Modifié par Mikachu (08 Jul 2007 - 13:32)

Bonjour,

Mikachu, tu as sans doute raison sur la forme et dans la politique générale mais
malheureusement, mes expériences semblent démontrer que l'essentiel est d'aboutir à tes fins ( le logiciel) pour assoir ton projet, limiter l'hémoragie financière et l'exploiter ( ou essayer de...)

S'il faut tenir compte immédiatement de l'essentiel ( W3C, taille des polices, lisibilité etc ), la mobilisation des ressources doit être orientée sur le logiciel et sur la compatibilité aux navigateurs significatifs : sinon, tu (je) court le risque de partir en Croisade à mes frais et d'aboutir sur un jouet dont chaque fonctionnalité serait une usine à bio-gaz

Quand je constate la haute technicité nécessaire à développer une simple page irréprochable ( valide, compatible et accessible ) : j'ai bien peur qu'hélas très peu de petites entreprises aient les moyens intellectuels, humains, techniques et financiers pour rédiger des cahiers des charges dans ce sens...

Amicalement
Modifié par OlivierD (08 Jul 2007 - 13:55)

OlivierD a écrit :
Quand je constate la haute technicité nécessaire à développer une simple page irréprochable ( valide, compatible et accessible ) (...)

D'où la nécessité d'une certaine industrialisation du secteur, qui fonctionne aujourd'hui essentiellement sur le mode de l'artisanat (bien mais couteux), voire du bricolage ?

Merci pour vos réponses.

A vrai dire, je considère qu'il est préférable, pour toute application, intranet ou pas, de fournir une base solide... qui fonctionne en toutes circonstances.

Cela veut dire, pas d'infos véhiculées par la couleur, comme l'a dit Florent mais aussi pas de fonctionnalités qui reposent sur Javascript, y compris pour un intranet où chacun dispose de ce langage. Amha, ce qui compte avant tout, c'est plutôt de faire quelquechose de simple qu'on peaufine au fur et à mesure plutôt que d'intégrer d'entrée de jeu toute une panoplie d'artifices... "vendeurs" certes, mais souvent problématiques.

Par exemple, si je dois transmettre une information provenant de l'utilisateur à ma bdd, je laisse l'utilisateur la transmettre via un mécanisme simple (un clic) ce qui rend mon application opérationnelle dès les premières ébauches. Je n'ai plus qu'à annihiler le clic pour le remplacer par un autre mécanisme, un drag'n'drop avec un peu d'Ajax par exemple. Ainsi, je peux d'ailleurs me resservir des fonctions php définies au départ, si tant est que j'ai prévu une certaine "ouverture", bien sûr. En revanche, si je transmets d'emblée l'information via le drag'n'drop et l'Ajax sans prévoir d'autre modes de fonctionnement, j'insère une contrainte/gêne supplémentaire que l'utilisateur ne peut contourner.

Le problème n'est pas que l'application fonctionne pour un navigateur dans sa configuration de base mais plutôt comment faire pour rendre le tout utilisable tout en laissant plein pouvoir à l'utilisateur sur la manière dont il compte se servir de ce navigateur.

Peut-être que le drag'n'drop va poser problème à certains (celui qui navigue habituellement au clavier ou encore celui pour qui la pression continue sur le bouton de la souris est difficile). Le dernier cas est le plus problématique parce qu'il n'y peut pas grand chose. Le cahier des charges, lui en revanche, aurait pu le prévoir.

En intégrant un mécanisme de transmission des données basique dès le départ, l'utilisateur pouvait désactiver Javascript, ce qui n'engendre aucun coût supplémentaire pour l'entreprise. Si ce n'est pas prévu, par contre, mais que l'utilisateur (admettons... un décisionnaire) doit pouvoir y accéder, il faut tout revoir parce qu'on n'aura même pas une base sur laquelle se reposer.

Donc, ok pour le fait qu'on peut se servir des fonctionnalités avancées d'un outil mais on ne contrôle pas l'utilisateur. C'est une des raisons pour lesquelles j'opère toujours par surcouches successives, en fournissant un mécanisme simple puis en l'améliorant.

OlivierD a écrit :
Quand je constate la haute technicité nécessaire à développer une simple page irréprochable ( valide, compatible et accessible ) : j'ai bien peur qu'hélas très peu de petites entreprises aient les moyens intellectuels, humains, techniques et financiers pour rédiger des cahiers des charges dans ce sens...

Ce qui prend du temps, c'est surtout l'établissement d'un bon cahier des charges. Rendre une application fonctionnelle peut se faire assez vite mais se reposer sur des fonctionnalités (telles que le drag'n'drop) fait courir le risque d'une refonte. Je dis refonte parce que l'ajout d'un mécanisme supplémentaire est générateur d'usine à gaz. Les travaux supplémentaires seront là pour corriger un problème et non pour améliorer l'application, ce qui insère des contournements, inutiles s'ils avaient été pris en compte dès le départ.

En d'autres termes, en se fondant sur une fonctionnalité plutôt que sur l'utilisabilité, on gagne un ou deux jours au départ sur quelquechose qui se développe en deux semaines mais lorsqu'un problème surgit, on peut se retrouver avec deux semaines supplémentaires et une application plus lourde.

Il me semble donc préférable d'intégrer directement les critères liés à l'accessibilité plutôt que d'essayer de les rétablir.
Modifié par koala64 (08 Jul 2007 - 14:53)

En passant :

a écrit :
Pourquoi l'accessibilité numérique ?
A l'heure où certains pays se dotent d'une législation nationale sur l'accessibilité numérique, ce document rappelle les enjeux internationaux de l'accessibilité, et l'ensemble de ses bénéfices sociaux, financiers, techniques et managériaux.

Lire sur Openweb : Pourquoi l'accessibilité numérique ?.

Et aussi :

a écrit :
Mieux travailler ensemble grâce à l'accessibilité : 1. Qui pilote les projets Internet ?
Au sein des PMI ou des grands comptes, on voit fréquement des projets Internet ou intranet souffrir des effets pervers d'un double pilotage par les directions informatiques (DSI) et les directions communication.

Lire sur Openweb : Mieux travailler ensemble grâce à l'accessibilité, partie 1.

a écrit :
Mieux travailler ensemble grâce à l'accessibilité : 2.L'accessibilité et les standards pour désamorcer les sources de conflits
Dans la première partie de cet article, nous avons vu qu'il était quelquefois difficile de faire travailler ensemble des directions ou des personnes issues de cultures différentes. Dans cette dexième partie, nous allons voir comment l'accessibilité peut mettre tout le monde d'accord et limiter les sources de conflit.

Lire sur Openweb : Mieux travailler ensemble grâce à l'accessibilité, partie 2.
Modifié par Florent V. (08 Jul 2007 - 15:05)

a écrit :
Cela veut dire, pas d'infos véhiculées par la couleur, comme l'a dit Florent mais aussi pas de fonctionnalités qui reposent sur Javascript, y compris pour un intranet où chacun dispose de ce langage. Amha, ce qui compte avant tout, c'est plutôt de faire quelque chose de simple qu'on peaufine au fur et à mesure plutôt que d'intégrer d'entrée de jeu toute une panoplie d'artifices... "vendeurs" certes, mais souvent problématiques.

Je suis tout à fait d'accord, on oublie vite qu'internet et ses dérivées (intranet/appliwebs) sont avant tout des outils destinés à transmettre de l'information. A l'origine dans sa forme la plus brute.
Certes depuis on a créé des technologies complémentaires permettant de rendre les choses plus attractives, en y ajoutant le côtés visuel et dynamique. Mais on en subit à mon sens les effets pervers en tombant dans le "trop".

Les utilisateurs attendent surtout de trouver et d'accéder à l'information le plus rapidement et simplement possible. C'est le but de l'outil.

Les technologies "annexes" devraient n'intervenir qu'après la base, à savoir l'accès à cette information, pour rajouter pour ceux qui le peuvent la possibilité d'avoir quelque chose de plus convivial et attractif.

Sujet très intéressant et très complexe à la fois . C'est même (à mes yeux) la plus lourde et dure tâche à accomplir dans la conception et la réalisation d'un site.

Comme Koala64, je n'imagine pas développer un site (peut-on encore parler de site tant son but est désormais d'être utilisé comme une application à part entière ...) sans prendre en compte dès le départ la question de l'accessibilité. Son évolution serait compromise.

Après pour répondre aux interrogations de Koala64, il n'y a malheureusement pas de réponse ... trop de facteurs sont en jeu ...

Mais s'efforcer à prendre le maximum de disposition pour rendre un site utilisable dans de nombreux cas est un gage de qualité.

Pour terminer : on peut déterminer qu'un site est inaccessible ... le contraire n'est pas aussi évident ...

Bonjour à vous

Désolé, je n'avais pas vu cet échange...

Voilà peut être la phrase la plus importante de tout cet échange

yodaswii a écrit :
... on peut déterminer qu'un site est inaccessible ... le contraire n'est pas aussi évident ...

Je pense qu'il faut jouer la carte de la simplicité, ça n'empêche pas un certain esthétisme. Ensuite tu conserves en permanence près de toi un référenctiel accessibilité et dès que tu as un doute, tu le consultes pour voir si ce que tu mets en place ne comporte pas d'éléments qui pourraient rendre la page moins accessible ou pire.

Autre point important, ne cherche pas la perfection sinon ton projet ne verra jamais le jour

Il est préférable de proposer une première version de l'outil fonctionnelle, au même titre qu'il y aura certainement des bugs techniques à corriger, il y aura des éléments d'accessibilité à ajouter ou à modifier
Modifié par dominique (03 Aug 2007 - 10:40)

a écrit :
... il y aura des éléments d'accessibilité à ajouter ou à modifier

En effet mais dans le cas de modification, le développement sera sans aucun doute plus pénible d'où la question de koala64.

Il me semble qu'avant de se lancer il faut se fixer des objectifs afin d'éviter, comme le dit Dominique, que le projet tombe à l'eau du fait d'un extrémisme poussé de l'accessibilité.
Modifié par yodaswii (03 Aug 2007 - 14:46)