JSF et Accessibilité

L’obligation d’accessibilité se généralise dans de nombreux pays (États-Unis, France, …), mais il est étonnant de voir que certains frameworks de développement semblent se soucier si peu de cet aspect.

Le point fort de JavaServer Faces (JSF) est qu’il dispose d’un grand nombre de librairies de composants et d’outils de développement, ceci étant certainement lié au fait qu’il s’agit d’une partie du standard JEE.

Une particularité également intéressante de JSF, comparé à certains autres frameworks (Struts 2, Spring MVC, Symfony, …), est qu’il s’agit d’un framework orienté composants, s’éloignant donc du pattern classique MVC que l’on avait l’habitude de rencontrer dans les frameworks web.

Cependant, cette orientation composant s’accompagne également d’une orientation évènementielle, s’appuyant massivement sur du JavaScript (onclick(), onfocus(), …). Il s’agit d’une fonctionnalité importante de JSF, sur laquelle reposent la plupart des librairies de composants existantes, et donc incompatible avec le besoin d’accessibilité (WAI : « Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported »).

Une seule librairie semble avoir pris en compte la contrainte d’accessibilité : Apache Trinidad (également connue en tant que Oracle ADF Faces). Cependant, le réglage de l’accessibilité se fait de manière prédéfinie : dans le fichier de configuration trinidad-config.xml, on définit par avance si l’on souhaite un contenu privilégiant l’accessibilité (au détriment de l’ergonomie), alors que cela devrait être fait de manière automatique en fonction du client.

Une solution pour contourner ce problème est de créer ses propres composants (ou de modifier des composants existants), reposant d’une part sur la puissance JSF pour l’ergonomie, et gérant également le cas où le javascript n’est pas activé. Or, la difficulté de développer de nouveaux composants est précisément l’un des principaux points faibles de JSF.

Kito Mann, responsable de JSFCentral, auteur de « JSF in action », et membre du comité d’expertise JSF : « One of JSF’s biggest barriers is the complexity of UI component development. This is part of the reason Facelets has done so well (…). Tapestry has always had JSF beat hands-down when it comes to component development as well ».

JSF présente également d’autres points faibles, qui rendent difficiles certains développements (notamment la difficulté de traquer les erreurs d’expressions et de navigation en raison de l’absence de message d’erreur).

Tous ces points sont appuyés par un grand nombre de retours d’expériences mitigés sur JSF 1.2. La wishlist de JSF 2.0 s’allonge à vue d’œil, mais la prochaine spécification n’est pas prévue avant mi 2008, et il faudra attendre un moment encore avant de voir les premières implémentations (MyFaces, …) et retours d’expériences.

En conclusion, JSF est plutôt efficace lorsque l’on utilise des composants existants, mais dès lors qu’il faut modifier ou créer des composants (ce qui est nécessaire si l’on veut un contenu accessible), le développement devient laborieux.

En savoir plus :

– Wishlist JSF 2.0 de Kito Mann (responsable de JSFCentral)
– Wishlist JSF 2.0 de Gavin King (responsable de JBoss Seam, reposant sur JSF)
– Draft de JSF 2.0