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é).

Voilà un petit message d’erreur bien embêtant : « A drive with the name 'RDS' does not exist. »

Celui-ci se produit quand on souhaite utiliser Powershell pour manipuler une configuration RDS qui n’est pas configurable via les commandes standards (c’est le cas qu’on ne déploie que la passerelle).

Exemple :

Set-Item -Path RDS:\GatewayServer\SSLCertificate\Thumbprint -Value $thumbprint

Quand on connait un peu Powershell, il faut se poser la question du module qui est amené à fournir l’élément manquant et à l’importer. Dans le cas présent « RemoteDesktopServices ».

Il suffit donc d’ajouter la directive import correspondante pour que son script fonctionne correctement.

Import-Module RemoteDesktopServices

# ... un peu de code pour définir $thumbprint

Set-Item -Path RDS:\GatewayServer\SSLCertificate\Thumbprint -Value $thumbprint

Tout simplement.

Pour une intégration parfaite d’une VM Linux sur Hyper-V, il faut passer par l’installation d’outils. Historiquement Microsoft fournit Linux Integration Services.

Il faut alors:

• Télécharger l’iso.
• Monter l’iso.
• Installer les services.

Pour ceux qui aiment la facilité, il y a aussi le package hyper-v que l’on trouve pour de nombreuses distributions aujourd’hui.

Mais il y a aussi la solution de la distribution qui a compris qu’elle s’installait sur Hyper-v et qui installe toute seule ce qu’il faut. C’est le cas d’OpenSuse.

Dans le cas présent, j’ai voulu ajouter le package, et j’ai une réponse indiquant qu’il est déjà en place.

Et via ma console Hyper-V, je peux voir les IP de ma VM et demander son arrêt propre, sans problèmes.

Encore une raison de préférer Suse et OpenSuse pour les projets Linux ;)

PS : j’utilise la commande transactional-update au lieu de zipper, car j’ai pris l’habitude d’installer mes VM OpenSuse en mode serveur transactionnel pour automatiser et fiabiliser l’application des patchs.

Voici un petit message irritant au possible qu’il m’est déjà arrivé d’avoir à plusieurs reprises avec Git sur Windows, lié un repository distant Azure DevOps ou GitHub

“Git failed with a fatal error. could not read Password for…”

Avec Visual Studio, pas moyen d’avancer.

Avec Visual Studio code, on peut être amené à saisir un mot de passe. Mais c’est en réalité un token qui est demandé, et non un mot de passe. De plus, il faut le fournir à chaque utilisation.