Introduction

Il y a un peu plus d’un an, on m’a confié un projet d’intégration, avec une demande expresse d’accessibilité de la part du client (ce n’est pas tous les jours que cela m’arrive). Dans ce projet, de nombreux éléments d’interfaces riches étaient présents : onglets, carrousels, fenêtre modale, etc.

Plutôt que de foncer tête baissée, je me suis dit qu’il serait intéressant pour moi de réutiliser chacun de ces éléments : ils sont tous assez courants et standards sur des sites classiques. Cela me permettrait d’avoir des composants réutilisables, maîtrisés et adaptables à chaque cas (et accessibles de facto).

Le résultat de ce travail est jQuery Accessible plugins. C’est en cours d’amélioration, néanmoins ces plug-ins accessibles sont tout à fait utilisables. Au fil de ce travail, j’ai pu apprendre beaucoup de choses (sur l’accessibilité, le code, etc.), et notamment en tirer une approche commune à chacun de ces éléments d’interface, approche complètement empirique tirée de la pratique (erreurs, réussites, etc.).

Je vous propose donc de vous expliquer cette approche, qui comporte 5 étapes.

Approche de création de plug-ins accessibles

Bien entendu, avant de démarrer, il vous faut l’envie : appelez cela, l’étincelle, le déclencheur, la motivation, etc. : c’est le moment où vous avez une bonne raison de vous lancer dans la création d’un plug-in.

Comme expliqué plus haut, pour ma part, c’était un projet qui a servi de déclencheur. Ajoutons à cela un besoin grandissant de plug-ins respectant certaines normes qualitatives que je trouvais difficilement ailleurs.

Un conseil : d’entrée de jeu, fixez vos priorités pour votre plug-in. Cela vous permettra :

• de ne pas vous disperser durant la création de votre plug-in ;
• et d’éviter du stress entre les étapes 4 et 5 (nous y reviendrons).

Pour vous donner une idée, voici mes trois principales priorités pour ces plug-ins :

• l’accessibilité bien sur : c’est la raison d’être de ces plug-ins, à savoir servir des utilisateurs ;
• un strict respect du principe d’orthogonalité et de l’amélioration progressive : de nombreux plug-ins existants ont souvent le gros défaut d’injecter des styles en ligne, c’est très handicapant pour adapter en responsive. Il est donc capital pour moi de respecter cet aspect qualitatif. Ajoutons à cela que l’amélioration progressive garantit une robustesse à toute épreuve.
• et une facilité d’utilisation : si je peux investir du temps pour en gagner ensuite, il m’est difficile de passer 1 heure pour installer ces plug-ins sur des sites, je dois – ainsi que mes collègues – pouvoir les déployer en quelques minutes.

Note : cela ne veut pas dire que d’autres aspects qualitatifs comme la performance seront purement et simplement ignorés. Ils seront simplement moins prioritaires s’il y a un choix à faire.

Étape 1 : réunir la(les) connaissance(s)

Avant de coder quoi que ce soit, il faut savoir ce que l’on veut obtenir, et comment on va le faire. Il faut donc lire de la documentation et acquérir certaines connaissances. En matière de composants d’interfaces riches, le document de référence est WAI-ARIA 1.0 Authoring Practices, design patterns. Cette page explique les design patterns, autrement dit les bonnes pratiques en terme de conception de ces composants.

Comme une de mes priorités est l’accessibilité, et n’étant pas expert dans ce domaine (ce n’est pas mon métier proprement dit), il y a deux possibilités :

• acquérir la connaissance moi-même ;
• ou me faire aider par des experts dans le domaine.

Cette seconde option sera préférée, sans m’en rendre compte au début, elle suit parfaitement le concept dit d’accessibilité agile : les experts accessibilité [1] me guideront et m’aideront sur leur domaine, de manière peu formelle, en m’accompagnant autant que possible tout le long de chaque plug-in. Plus ils seront là en amont, plus les risques des voies sans issue seront limités.

Il y a la motivation, les priorités et la/les connaissance(s) : vous pouvez passer à l’étape suivante !

Étape 2 : créer un prototype

Concevoir un site est compliqué : vous devez respecter une maquette et vous avez plein de contraintes diverses et variées. Dès lors, pourquoi ajouter une couche supplémentaire de complexité ? C’est admirable de vouloir tout résoudre d’un coup, mais pourquoi se compliquer la vie ?

Concentrez-vous sur un seul aspect, isolez et réduisez votre problème. À cette étape, vous avez besoin d’une seule chose : que cela marche. Si vous n’avez qu’une chose à retenir, dites-vous ceci :

« Un prototype n’a pas besoin d’être optimisé, ni même d’être beau. »

Faites donc un exemple sans aucun graphisme, tant que vos experts accessibilité n’ont pas dit « ok », cela ne sert à rien d’aller plus loin (si votre expert accessibilité vous dit que l’approche n’est pas bonne, vous devrez jeter à la poubelle tous vos efforts sur le design, donc autant n’en faire aucun). Le code n’a même pas besoin d’être optimisé, il faut que cela marche : vous travaillez sur le fonctionnement, et c’est tout !

Pour vous donner un exemple, un prototype d’onglets ARIA ressemble à cela :

Oui, c’est spartiate, ce n’est pas beau, mais cela suffit bien.

Une fois que vos experts vous ont donné le feu vert sur le fonctionnement et uniquement quand ils l’auront fait, vous pouvez passer à l’étape suivante.

Étape 3 : tester le prototype en situation réelle

Maintenant que vous avez le fonctionnement, vous pouvez tester ce travail sur un site réel. Cela vous permettra d’éprouver votre travail avec de vraies contraintes de production.

Un bon indicateur est le temps que vous allez passer pour insérer. S’il vous faut 5 heures de sueur pour arriver péniblement à le faire fonctionner, c’est plutôt mauvais signe, il faudra peut-être revoir l’approche. Par contre, si en 15 minutes, votre plug-in s’insère bien et apporte le fonctionnement qu’il est censé amener, c’est de très bon augure !

Autre avantage : en le testant sur un site réel, vous construisez un minimum viable. Par exemple, vous allez voir quels sont les styles nécessaires pour le faire fonctionner, vous allez ajouter des options pour le rendre modulable, stylable à souhait, utilisable dans des contextes différents, etc.

Idéalement, si vos experts accessibilité peuvent jeter un œil, c’est mieux, mais l’étape du prototype a dû limiter les risques, c’est tout l’intérêt de prendre ces problématiques en amont.

Maintenant que votre plug-in a passé l’épreuve du feu des conditions réelles, la plus terrible étape se profile…

Étape 4 : la vente et le marketing

Oui, je parle bien de vente et d’accessibilité dans la même phrase. D’ailleurs, ce n’est plus un plug-in, mais un produit qu’il va falloir vendre via une approche marketing. Si si, je suis très sérieux.

Bien entendu, je ne parle pas d’argent sonnant et trébuchant. Je parle de crédibiliser votre travail, et ce, même si vous êtes la seule personne à vous en servir. Voici de quoi vous faire prendre conscience de l’importance de cette étape.

Premier cas : la prise de conscience

Je discute avec une connaissance [2], il me dit qu’il a utilisé un de mes plug-ins, qu’il l’a trouvé très bien, et il souhaiterait savoir s’il existe une page pour le mentionner ou en parler. Là, ne doutant de rien, je lui envoie la page… du prototype.

J’imagine son regard plein de condescendance et de stupéfaction en tombant sur cette page, et il me dit très justement :

« on ne peut pas montrer cela. »

Effectivement, on ne peut pas montrer cela. Cela ne fait pas sérieux ! Je n’en avais pas pris conscience. Imaginons un cas tout aussi plausible…

Limiter les risques avec les clients

Lors d’un projet, un client me fait part de son souhait d’avoir une page avec les mentions légales, comme les crédits photographiques, etc. Je le félicite : c’est une bonne pratique, et je suis content que la demande vienne de lui. En général les clients oublient ce point, et c’est à moi de leur rappeler.

Bref, nous mettons donc les mentions légales en place, et afin de respecter les licences des outils utilisés pour le développement du site (frameworks, plug-ins, etc.), je les mentionne dedans.

À votre avis, que va-t-il se passer si je fais un lien vers la page du prototype du plug-in ou vers une page pas très engageante ? Le client va réagir comme dans la première situation : on ne pas mentionner « ça ».

• il va dire que son site perd en crédibilité en mentionnant ce plug-in mal présenté ;
• de plus, la crédibilité du plug-in et de son créateur vont en prendre un coup (même si le code est excellent) ;
• et votre propre crédibilité de concepteur de site va baisser aux yeux du client : « vous utilisez des outils qui ne font pas sérieux ».

Autrement dit, votre prestige va en prendre trois fois pour son grade. Et pourtant : un minimum d’efforts aurait pu créer un effet totalement différent.

Crédibiliser votre produit

Que l’on soit bien d’accord :

• oui, c’est du marketing et de la communication (ce ne sont pas des gros mots pour autant) ;
• oui, cela ne garantit rien sur le code (mais cela rassure) ;
• oui, ce travail n’est pas parfait (quel code l’est ?) ;
• oui, vous êtes un codeur et pas « un marketeux ».

Ceci dit, il n’y a pas besoin de faire quelque chose d’extraordinaire : une page de présentation propre montrant les capacités de votre produit peut amplement suffire. Quand je parlais d’approche marketing, c’est simplement de vous poser la question si vous étiez le « client » de votre produit :

« En quoi ce produit est bien, qu’est-ce qui ferait que moi – client potentiel – je l’utiliserais ? »

Très simplement : listez les points forts de votre produit, et mettez-les en avant. Vos « clients » potentiels doivent voir très rapidement ces avantages.

Dans les deux situations précédentes, un lien vers cette page ne gênera personne. Au pire cela ne sera pas remarqué, au mieux cela renforcera votre crédibilité.

Très logiquement, si vous allez au bout de la logique « marketing », une fois cette page terminée, vous allez en faire la promotion : en parler sur les réseaux sociaux, dans les milieux autorisés, etc.

Cela vous amène à la « dernière » étape.

Étape 5 : la vie du plug-in

Logiquement, le fait d’en parler va vous amener des retours. Des idées, des suggestions, des ajouts, des corrections de bugs, des aspects auxquels vous n’avez pas du tout pensé, etc.

Ajoutons à cela que les réseaux sociaux ont un effet quelque peu pervers : tout va arriver sur une période très courte et très condensée. Même sans avoir une immense notoriété, ces retours peuvent rapidement être nombreux et chronophages. Et comme toute personne, vos journées ne font que 24 heures.

C’est là que les priorités que vous avez posées au tout début vont se révéler essentielles : elles vont vous aider à prioriser tous ces retours. Cela ne veut pas dire que les non-prioritaires seront remis aux calendes grecques, juste qu’en cas d’hésitation, ils pourront sagement attendre.

Note : ne craignez pas cette mise en avant et ces retours. Si cela peut vous rassurer, je peux bien vous le dire : je n’ai pas eu un seul retour inintéressant jusqu’à présent pour ces plug-ins accessibles.

Ensuite, votre plug-in va avoir sa propre vie : des ajouts, des améliorations, etc. Les étapes (connaissances, prototype, tests réels, promotion) restent valables à chaque itération. Ce n’est pas la fin, c’est le début du commencement !

Conclusion

Même si cela peut être tentant : ne négligez aucune de ces étapes. Elles sont toutes essentielles et vous permettront de construire des plug-ins solides, fiables et en phase avec la réalité de la production. Gaël Poupard le disait bien dans « Du consommateur au producteur » :

Nous avons traversé quelques COQ

Effectivement, ce temps « investi », ce coût d’obtention de la qualité, n’est pas négligeable. Néanmoins, il va vous apporter d’immenses bénéfices. Pour ma part, c’est déjà une forte montée en compétence dans plusieurs domaines (accessibilité, développement, etc.). Ensuite, ce temps investi va être récupéré dans les projets suivants où ces éléments vont être réutilisés.

Assurément, pour votre entreprise et vis à vis de ses clients, vous pratiquerez le “Eat your own dogfood”, autrement dit vous utiliserez vos propres solutions afin de les éprouver et de constamment les améliorer. Cela montrera une certaine confiance en vous et vos produits.

Bien entendu, la motivation à l’amélioration sera bien plus grande et constante avec vos propres solutions, cela va sans dire (et ne parlons pas de la rapidité du support d’une solution maitrisée).

Et disons-le clairement : c’est extrêmement plaisant de devenir « producteur » au lieu de « simple consommateur ».

Références, compléments

• L’accessibilité agile
• L’accessibilité agile, de la théorie à la pratique
• Du consommateur au producteur
• WAI-ARIA 1.0 Authoring Practices
• Accessibility section - jQuery Plugins