fplanque: blog geek

Dans Plongez dans l'accessibilité - 30 jours pour rendre un site web plus accessible, Mark Pilgrim (traduction Karl Dubost) explique un certain nombre de règles simples permettant de rendre un site web (en l'occurrence un weblog) plus accessible ainsi que les bénéfices que vont pouvoir en tirer certaines personnes souffrant de handicaps physiques, mentaux ou technologiques...
Toutefois, je pense que l'accessibilité bénéficie à une population beaucoup plus large que les personnes handicapées. Tout le monde en bénéficie! En effet, en appliquant les techniques d'accessibilité votre site bénéficie automatiquement des avantages suivants:

• Il sera mieux indexé et mieux référencé dans les moteurs de recherche
• Il pourra être projeté dans une sale de réunion sans être illisible car écrit trop petit
• Il pourra être consulté sur un téléviseur (webTV)
• Il pourra être consulté sur un PDA ou un téléphone mobile
• Il pourra être imprimé correctement
• Il sera plus agréable à lire pour les utilisateurs assidus qui voudront probablement régler la taille des caractères en focntion de leur niveau de fatigue visuelle ou de la résolution de leur écran
• Et j'en oublie...

Dans la suite logique de l'accessibilité, il est tout aussi important de veiller à la bonne impression de vos pages... pour tous ceux qui ne sont toujours pas prêts de s'habituer à lire sur écran et ils sont nombreux, comme le rappelle judicieusement pompage.net ce mois ci, explications à l'appui.

Deux petites astuces tout de même pour ceux qui peinent à lire sur écran:

1. apprenez à régler la fréquence de rafraichissement de votre écran à plus de 60 Hz! Cette valeur par défaut est scandaleusement basse par rapport aux possibilités du matériel actuel. En passant, ne serait-ce qu'à 75 Hz, la diminution du scientillement aura un effet non négligeable sur votre fatigue visuelle.
2. essayez l'écran plat! De préférence avec une connexion DVI (numérique) plutôt que VGA (analogique) afin de garantir une netteté optimale. là encore, le gain de confort va de pair avec la diminution de fatigue visuelle.

Le sujet est dans l'air, on en parle sur StandBlog, chez Russell Beattie, plusieurs autres blogs et même le Journal du Net. C'est plutôt une bonne chose que l'on commence à s'en préoccuper un peu dans notre pays, même si nous n'avons pas de lois pour nous y obliger comme aux US... L'intérêt de rendre un site web plus accessible va d'ailleurs bien au delà du fait qu'il devienne plus accessible aux handicapés! En effet, combien de sites, designés par une agence quelconque, vous affichent des pavés de texte écrits en 6 points (ou encore 8 pixels de hauteur), vous forçant à vous rapprocher de votre écran pour pouvoir lire ce qui est écrit? Mais voyez vous... il parait que c'est plus design... Moi ça me rappelle plutôt les conditions générales de ventes imprimées de manière illisible au verso des bons de commande! Messieurs les créatifs, vous n'avez rien compris! Les lecteurs ne peuvent pas passer leurs journées à lire des tous petits caractères... (et pour les conditions de vente, figurez vous que c'est fait exprès! ;)


Il est important également de constater le fait que vous pouvez effectivement lire des petits caractères... mais que celà devient de plus en plus pénible au fur et à mesure que la journée avance et que la fatigue s'accumule... C'est également plus gênant lorsque le texte à lire est long: on ne peut pas lire un white paper en tout petit même si on peut le faire sans problème pour une brêve.


S'ajoutent à celà, les critères purement techniques de résolution d'écran utilisée par le lecteur. Un écran d'ordinateur affiche probablement entre 60 et 120 points par pouce selon la résolution et la taille de l'écran. Par exemple, des caractères de 12 points seront bien plus gros sur un écran 19 pouces configuré en 800*600 que sur un écran de portable de 15 pouces configuré en 1600*1200!


En fait, la bonne taille de caractères dépend donc intimement de la situation de chacun et il semble dès lors extrêmement prétentieux de vouloir déterminer à l'avance la taille dans laquelle l'utilisateur voudra lire un texte.


Les browsers web permettent depuis assez longtemps de changer la taille des caractères... ce qui fût bien agréable pendant une certaine époque... avant que n'apparaissent les feuilles de styles! Celles-ci ont en effet tendance à figer la taille des caractères quelle que soit la taille réglée dans le menu du navigateur. C'est surtout le cas de Internet Explorer (même en version 6) alors que Netscape 7 par exemple, s'affranchit finalement assez bien du problème.


Pourtant, il existe une solution relativement universelle: n'indiquer dans les CSS que des tailles de caractères sous forme de pourcentages! Ils pourront dès lors être redimensionnés à loisir par l'utilisateur.


A ce propos, connaissez vous les raccourcis clavier bien pratiques? Sous Netscape, faites Ctrl + pour augmenter la taille et Ctrl - pour la diminuer. Sous Internet Explorer, maintenez la touche Ctrl pendant que vous tournez la molette de la souris!

Essayez sur cette page, vous verrez!

[Ce post a été déterré de mes archives 1999]

Aujourd'hui j'ai été initié au terrible secret de fabrication de la déplorable médiocrité des traductions de nos logiciels quotidiens! En effet, dans le cadre d'un recrutement de chef de projets, nous avons aujourd'hui reçu un candidat ayant précédemment travaillé dans une SSII de traduction industrielle. Et non des moindres, puisqu'il était en charge de la traduction en français d'un environnement de développement assez connu permettant de réaliser des programmes Windows en disposant "visuellement" des objets et en tapant quelques lignes de Basic... (oui oui on parle bien de la même chose)!

Voici comment il procédait (selon une tradition qui se transmet de collaborateur en successeur depuis la nuit des temps de la localisation): un outil "très astucieux" commence par extraire toutes les chaines de caractères de tous les fichiers source et ressource du projet complet (je parle bien de l'environnement de développement complet!). Il en génère ensuite un fichier Excel dans lequel on retrouve le nom du fichier source, la position, le texte en anglais... reste une colonne vide pour le texte en français! Le gros du travail consiste alors à traduire les chaines de caractères ligne par ligne avant que le "très astucieux" outil ne réintègre ces traductions aux sources!!!

Moi: Mais... et le contexte?
Lui: Comment ça le contexte?
Moi: Oui, une même phrase, ou pire: un mot isolé n'a pas forcément la même traduction selon le contexte!!??
Lui: Oui, mais c'est rare... et dans ce cas, les testeurs nous le signalent lors de la phase de tests.
Moi: Ah? Et les testeurs passent par tous les écrans en comparant l'anglais et le français pour voir si le sens est respecté? Ils provoquent également l'affichage de tous les messages d'erreur?
Lui: Je ne sais pas... je n'ai pas participé aux tests.
Moi: Et vous même, quand vous traduisez, vous vous basez sur votre expérience en programmation?
Lui: Je ne suis pas programmeur!
Moi: Ah? Et ça ne pose pas de problème pour traduire un environnement de développement?
Lui: Vous savez, un logiciel reste un logiciel. D'ailleurs, sur les logiciels bureautiques [du même éditeur] les traducteurs ne sont pas non plus forcément des utilisateurs avancés, mais ce n'est pas un problème. Ce qu'on demande aux traducteurs, c'est de traduire, pas de refaire l'interface!
Moi: Passons à autre chose...

Après cette discussion, j'en suis à me demander comment les logiciels traduits en français arrivent tout de même à séduire certains utilisateurs...

Hum... probablement ceux qui ne parlent pas anglais, ne lisent pas les messages d'erreur par principe et n'ont jamais tenté d'ouvrir les options avancées, voire ne serait-ce que l'aide en ligne!

[Ce post a été déterré de mes archives 1998]

Exemple concrêt:

1. Un utilisateur souhaite transmettre son numéro de carte bancaire à un serveur de manière sécurisée.
2. L'utilisateur doit chiffrer son message (en l'occurence son numéro de carte) grâce à une clé. Et le serveur doit déchiffrer le message grâce à une clé.
3. Si on utilisait une méthode de chiffrement simple (symétrique), l'utilisateur et le serveur devraient au préalable se mettre d'accord sur une clé de chiffrement/déchriffrement secrête et connue d'eux seuls afin que personne d'autre ne puisse déchiffrer le message.
4. Cet échange de clé secrête n'est pas possible par Internet, car si on pouvait se transmettre secrêtement une clé, on pourrait directement se transmettre secrêtement le numéro de la carte bancaire. On tourne en rond...
5. La solution consiste à utiliser une méthode de chiffrement asymétrique: le chiffrement se fait avec une clé et le déchiffrement se fait avec une autre clé. Bien sûr, pour toute clé de chiffrement il n'existe qu'une seule clé de déchiffrement possible. Ces clefs fonctionnent donc exclusivement par paires.
6. Le serveur définit donc une paire de clefs. Il en garde une secrète (la clef privée). Il en donne une autre à tous ses utilisateurs (la clef publique).
7. Dès lors, tout utilisateur peut chiffrer son message avec la clef publiquer et l'envoyer en toute confiance au serveur qui sera le seul à pouvoir le déchiffrer car il est le seul à posséder la clef privée, indispensable au chiffrement.
   
   Note: en réalité, le browser va chiffrer une clef master aléatoire qu'il va envoyer au serveur qui est le seul à pouvoir la déchiffrer avec sa clef privé. Cette clef master est ensuite utilisée pour chiffrer à la fois les messages envoyés au serveur et les messages reçus du serveur. Toutes les informations échangées entre le browser et le serveur sont ainsi cryptées.
8. Mais ça ne suffit pas. En effet: que se passe-t-il si jamais une personne malveillante diffuse une fausse clef publique? Le message chiffré envoyé par l'utilisateur ne sera plus déchiffrable par la clef privée du serveur. Par contre il sera déchiffré facilement par le pirate qui possède la clef privée correspondant à la fausse clef publique.
9. Il est donc indispensable que l'utilisateur soit sûr d'utiliser la BONNE clef publique.
10. Pour être sûr, il dispose d'un certificat émis par une Autorité de certification et qui certifie que la clef est la bonne.
11. Mais comment être sûr que le certificat n'est pas un faux? Réponse: parce qu'il est signé électroniquement par une aurtorité de certification (AC) connue à l'avance. (Une liste d'AC est préenregistrée 'en dur' dans le browser Web).
12. La signature électronique fonctionne sur le même principe: l'AC chiffre le certificat avec sa propre clef privée et l'utilisateur déchiffre le certificat avec la clef publique de l'AC. Rappelons qu'il connait cette clef publique à l'avance car les AC et leurs clefs publiques sont préenregistrées dans le browser Web.