Bootstrap-select est un complément bien sympathique à Bootstrap (pour ceux qui ne connaissent pas, il se trouve ici). Malheureusement, sa dernière version a inclue un changement qui peut poser problème (version 1.13.10).

Si vous utilisez la méthode selectpicker avec l’argument "deselectAll", et que l’utilisateur n’a rien sélectionné dans votre liste, vous déclencherez une exception.

Pour éviter le problème, il faut :

• Utiliser selectpicker("refresh") quand votre liste est vide.
• Utiliser selectpicker("deselectAll") quand votre liste n’est pas vide.

Exemple avec désactivation du control :

var ctrl = $("#controlId");
ctrl.prop("disabled", true);
if (ctrl.val().length === 0) {
    ctrl.selectpicker("refresh");
}
else {
    ctrl.selectpicker("deselectAll");
}

La documentation de Bootstrap fait souvent état de l’usage d’ancres utilisant un # dans son href.

<a href="#" onclick="Foo()">...</a>

Niveau accessibilité, si on vous demande d’avoir un site qui fonctionne sans JavaScript, le lien sera inutilisable (oui, on peut encore vous demander cela en 2019).

Je n’entends pas refaire une explication ici des différents concepts de sémantique HTML, rôle ARIA … etc …. L’objectif est uniquement de rappeler que l’on peut avoir un lien fonctionnel avec et sans JavaScript.

Pour que le lien soit utilisable, il faut prévoir deux comportements :

• Le premier avec JavaScript : ouvrira certainement une boite de dialogue.
• Le second sans JavaScript : déclenchera la navigation vers une page.

Pour un site .net MVC, cela est plutôt facile. Il suffit de prévoir deux vues :

• Une vue partielle pour l’encapsulation dans la boite de dialogue
• Une vue qui embarque la vue partielle pour permettre la navigation de l’utilisateur sans JavaScript.

Côté HTTML de l’ancre, cela n’est pas compliqué.

<a href="/Controller/Action" onclick="Foo(); return false">...</a>

Comme cela, c’est un peu plus clair et cela fonctionne avec et sans JavaScript :

• Le lien sert de bouton.
• Avec JavaScript, au clavier, il fonctionnera comme un bouton.
• Avec JavaScript, il fonctionne au click.
• Sans JavaScript, on lance une navigation.

Old school, mais utilisable.

Pour une écriture plus propre, la fonction Foo() peut directement retourner false.

Avant d’en dire plus long, sachez que je suis un fervent défenseur de la dématérialisation. Je trouve louable, toute initiative qui conduit à rendre une démarche possible à toute heure de la journée et sans avoir à utiliser papiers et enveloppes. Si en plus cela concerne des services publics, je suis très enthousiaste.

Malheureusement, je suis aussi défenseur de l’accessibilité. C’est ce qui me conduit à écrire cet article.

Trop souvent, quand une société entame un processus pour rendre accessible un service, elle part avec deux préjugés :

• L’accessibilité ne concernerait que les aveugles.
• L’accessibilité n’existe que pour le web.

Aucune de ces idées n’est vraie. Pour résumer simplement :

• L’accessibilité est pour tous.
• L’accessibilité se pratique sur tout support numérique.

Quand on dit « tous », de qui parle-t-on ?

Bien évidemment, quand on parle d’accessibilité, on pense handicap. Mais quand on pense handicape, on fait une nouvelle erreur. On ne s’attache qu’aux handicaps visibles :

• Aveugles.
• Personnes en fauteuil roulant.

La liste est un peu trop courte. Si l’on prend le temps de regarder du côté d’une norme comme le RGAA, on se concentrera sur les difficultés :

• Sensorielles.
• Mentales.
• Motrices.

Concrètement, on ajoutera toutes les personnes qui :

• On des problèmes de vue partielle (vue périphérique ou centrale limitée, cataracte, glaucome, rétinopathie ... etc.).
• On des difficultés à discerner les formes (problème de vue, ou trouble Dys).
• On des difficultés à percevoir les couleurs (voir incapacité totale).
• On des difficultés à manipuler une souris et/ou un clavier (voir incapacité totale).
• On un handicap mental, ou un trouble passager qui perturbe leur résonnement et la capacité à s’adapter (choc à la suite d’un accident, fatigue, stress).
• On un trouble de la mémoire ou de l’attention (Alzheimer, autisme, mémoire peu développée).
• … etc.

S’ajoutent à cela les cas que l’on oublie toujours (volontairement ou non) :

• Sourds ou mal entendant (je ne sais pas pourquoi on les oublie si souvent).
• Les personnes qui n’ont jamais utilisé un ordinateur, une tablette ou un mobile (ou qui changent de systèmes d’exploitation).
• Les personnes âgées (que l’on oublie de moins en moins).

Toute personne qui peut avoir des difficultés à utiliser votre application ou votre site est concernée.

L’accessibilité est donc un sujet qui concernera tout le monde un jour ou l’autre, ponctuellement ou continuellement.

Quand on dit tout support, lesquels ?

Pourquoi se limiter à rendre un site accessible ? Quand une personne accède à un site accessible, il faut bien évidemment qu’elle dispose d’un navigateur. Celui-ci doit donc être accessible. Pour pouvoir lancer le navigateur, il faut un système d’exploitation. Celui-ci doit aussi être accessible. Aujourd’hui, on trouve un navigateur sur les ordinateurs, les tablettes et les mobiles. Il faut donc que ceux-ci soient accessibles. L’accessibilité commence donc dès l’appui sur le bouton « On » de votre matériel.

Il n’y a donc pas de raison de se limiter. Rendre un site accessible n’est donc qu’une partie du travail.

Quand vous développez et distribuez une application, il serait donc bon qu’elle soit aussi accessible. Sans quoi, vous allez perdre une partie de vos utilisateurs potentiels (et donc, des parts de marché).

Si vous travaillez à destination des marchés publics (services publics, état français, collectivités …etc.), c’est une obligation. Dans ce cadre, c’est vous qui êtes responsable et non l’organisme prescripteur, ou l’acquéreur (contrairement à ce que laisse croire la légende urbaine). Si vous être pris à défaut et mis en demeure, vous risquez de ne plus être en mesure de distribuer vos produits dans le cadre de marchés publics. Il y a aussi la possibilité de se voir contraint de dédommager les personnes lésées pour le préjudice causé (je ne sais pas si cela a déjà eu lieu).

Moralité

L’accessibilité, c’est bien partout et pour tous.

Nombre d’applications, et site web utilisent des messages génériques pour indiquer à l’utilisateur qu’une erreur est survenue. L’utilisateur peut alors se trouver dans une impasse. Il lui est impossible de savoir ce qui s’est passé et ne peut faire que des suppositions.

À mon sens, il y a là un défaut d’accessibilité, car l’utilisateur est dans l’incapacité d’utiliser l’application. S’ajoute à cela la frustration qui fait que votre utilisateur risque de faire l’impasse sur votre service. Sans compter le stress produit s’il s’agit d’un service critique que celui-ci ne peut pas éviter (stress et la perte d’orientation sont des critères que l’on associe de plus en plus à l’accessibilité).