Et si on arrêtait de croire qu’une appli web est une page web ?
Quentin VUILLIOT
2

Choisir les bons outils

En réaction à cet article, j’ai eu quelques échanges intéressants, notamment concernant l’accessibilité, qui nécessitent que j’approfondisse un peu : j’ai exposé une distinction entre “service” et “document” qui est discutable (et qui doit être discutée !), car la réalité n’est pas manichéenne.

Le véritable point de ma réflexion, c’est qu’il faut faire l’effort de poser les besoins et contraintes de chaque projet, pour choisir les technologies adaptées en fonction. Et ne pas se référer à de “bonnes pratiques” qui ne seraient pas adaptées à notre cas.

Souvent, les bonnes pratiques que l’on retrouve sont issues de l’origine du Web, quand il n’y avait que des pages Web, dont l’objectif est de fournir du contenu, à base de texte et d’images. On recommande alors, pour une accessibilité au plus grand nombre, de bien structurer le document en HTML, puis d’avoir recours à CSS ou JS uniquement en bonus.

Mais on utilise maintenant les technologies Web pour faire autre chose que de simples pages : des applications riches, pour la simple raison que c’est devenu l’environnement multi-plateforme par excellence. Et pour cela, peut-être vaut-il mieux suivre des bonnes pratiques liées au développement de logiciels que les bonnes pratiques HTML.

Donc pour prendre quelques exemples :

  • Page de présentation d’un article sur un site marchand : page Web, HTML/CSS classique.
  • Formulaire de recherche d’un site marchand : c’est déjà une application simple; l’objectif est de faire une requête au serveur pour qu’il réponde une page de résultats. Si l’accessibilité est souhaitée au plus grand nombre, même les utilisateurs sans JS, HTML dispose d’éléments de formulaire qui vont permettre de rendre ce service a minima. Si JS est autorisé, on peut faire des formulaires plus avancés, et pour l’accessibilité avec des composants non-natifs, il y a ARIA.
  • Framavectoriel (appli) : le service à rendre est de pouvoir dessiner. Accessibilité à des non-voyants, par exemple ? Difficile … Choix des technologies : JavaScript + SVG indispensable, HTML/CSS peu adapté.
  • Application riche uniquement destinée aux aveugles : JS + ARIA sont bien adaptés, HTML/CSS pas tellement.

Je pourrais allonger la liste avec d’autres combinaisons de besoins/contraintes qui amèneraient à d’autres choix de technos, mais je crois que ça suffit ☺.

Dans ma société, nous nous intéressons plutôt aux cas d’applications riches à ergonomie graphique avancée qui ne sont pas destinées aux personnes handicapées. Il vaudrait sûrement mieux concevoir des versions de l’application dédiées aux différents handicaps, si le besoin se présentait.

Pour ces cas-là, nous pensons qu’une architecture en composants JS est plus adaptée, et nous allons bientôt présenter notre solution, dès que l’on trouve le temps !

Like what you read? Give Quentin VUILLIOT a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.