#AccessibiliteNumerique côté #Backend, encore une question à soulever quand met en place une stratégie. Citons cet article de Allen Pike.
Que soulève Allen dans son article : La fatigue #JavaScript fait des ravages ?
Et aujourd’hui, nous avons un problème de riche : des outils puissants pour une multitude de cas d’utilisation. Qu’est-ce que j’aimerais que les choses se calment et soient chiantes !
Pourquoi dit-il cela ?
Dans son article, il retrace l’utilisation de #JavaScript et ses différents #FrameWork les 10 dernières années : #ReactJs, #NextJS… il montre que leur fonctionnement peut provoquer souvent pas mal de travail supplémentaire :
Lorsque nous choisissons d’adopter une nouvelle dépendance (modules ou autre) : nous faisons un pari (we are making a #bet).
A ce que je comprends, l’article semble parler de la correspondance entre le projet qu’on souhaite réaliser et la #Technology choisie. Si ce n’est pas la bonne, on va devoir tordre le code.
Il évoque ainsi les #BoringTechnology, pas à la pointe des dernières tendances, mais tellement moins créatrices de problèmes non anticipés.
Mais alors, si on doit dégager du temps, de l’argent… pour rendre un #ServiceNumerique #Accessible, mais que la technologie pour ce même projet n’est pas la bonne ?
Trop de temps sera passer sur la maintenance du code à chaque modification, plutôt que sur des évolutions ?
Qu’est-ce qu’on fait ? A quel moment, on remet en cause le choix de techno ? Quelle serait la bonne techno ? Comment on re-ventile des budgets ? Comment on remet en question les compétences techniques des personnes du projet ? Avec quels indicateurs, on suit ce service ?
Les #innovations peuvent aller à l’encontre de l’#AccessibiliteNumerique et même rendre toute intervention pour améliorer le code #HTML sans impact réel sur le parcours usager.
Pour améliorer l’#UX, il faut parfois avoir la capacité d’identifier les réelles causes du défaut qualitatif d’un produit. Mais aussi être en mesure de les rendre évidentes à toute une chaine de production.