Une intéressante initiative qui a pour but de remplacer la souris, par deux petits capteurs, collés au bout des doigts, dont les mouvements sont capturés par la wiimote.

Une vidéo très bien faite explique tout cela :

On imagine le grand intérêt que cela peut avoir pour les personnes qui ne peuvent pas manier une souris.

Plus d'infos sur le blog de Hubert Wassner à l'origine du projet : Wii-help ça progresse fort !

Un intéressant billet sur l'importance de proposer une alternative accessible à l'utilisation du javascript : Javascript et accessibilité

Le RGAA (dont la version pdf est disponible sur le site Synergies) consacre un point de contrôle à ce sujet :

Point de contrôle : 6.3 Proposer une alternative au code javascript et aux éléments programmables

Description

Libellé

S'assurer que les pages ne perdent pas d'informations lorsque javascript ou les éléments programmables sont désactivés ou non supportés. Lorsque ce n'est pas possible, fournir une information équivalente de manière alternative.

Objectifs et intérêt

Permettre l'accès à l'information et l'utilisation du site, même lorsque les navigateurs ne lisent pas javascript ou ne disposent pas du programme nécessaire au bon fonctionnement de l'élément programmable.

Niveau WCAG1.0

Niveau A

Références

• WCAG1.0 : directive 6
• DGME1.0 : points : 1.1, 4.1, 7.1,11.7
• Section 508 : points : 1194.22 (l), 1194.22 (m)

Impact

Profil communicant Profil développeur et intégrateur Profil rédacteur et contributeur

Mise en oeuvre

Explication

Les éléments programmables sont :

• Le contenu affiché via l'élément applet,
• Le contenu affiché via l'élément object,
• Le contenu affiché via l'élément embed.

Les utilisateurs ont besoin d'une alternative dans les cas suivants :

• Désactivation de javascript,
• Désactivation de java,
• Désactivation d'activex,
• Utilisation d'un navigateur ne supportant pas javascript, java ou activex,
• Absence du plugin nécessaire à la bonne visualisation de l'élément programmable,
• Blocage du javascript dans un environnement sécurisé sans pour autant le désactiver,
• Utilisation d'une aide technique n'interprétant pas correctement le code javascript.

L'alternative au code javascript se fait par :

• L'utilisation d'un l'élément noscript reprenant l'ensemble des informations fournies par le script,
• la conception de code javascript non obstrusif venant s'appliquer lors du chargement de la page. Cela permet ainsi d'avoir une page d'origine fonctionnelle et accessible, uniquement enrichie de fonctionnalités non bloquantes lorsque javascript est activé,
• L'utilisation d'un langage côté serveur.

Il est à noter que l'utilisation de l'élément noscript comme unique solution d'accessibilité est hasardeuse. En effet, cet élément n'est affiché par le navigateur ou lu par la synthèse vocale que si l'utilisateur a explicitement désactivé javascript.

L'alternative aux éléments applet se fait par :

• L'ajout d'un contenu alternatif, reprenant l'ensemble des informations présentes dans l'élément, avant la fermeture de l'élément,
• L'ajout d'un lien vers une page reprenant l'ensemble des informations présentes dans l'élément.

L'alternative aux éléments object se fait de la même façon que celle des éléments applet. De plus, il est possible d'imbriquer plusieurs élément object, appelant des contenus différents, les uns dans les autres.

L'alternative aux éléments embed se fait par l'ajout d'un contenu alternatif, placé dans un élément noembed, et reprenant l'ensemble des informations présentes dans l'élément.

Exemple

Utilisation de l'élément noscript pour une alternative à une fonction lançant la fenêtre d'impression en javascript :

[html]
<script type="text/javascript">
function imprimer(){
document.write('<a href=\"javascript:window.print()\">Imprimer cette page<\/a>');
}
imprimer();
</script>
<noscript> Pour imprimer cette page, utiliser la fonction d'impression de vos navigateur, si vous ne savez comment faire reportez-vous à <a href="aide.html#impression">la page d'aide</a> </noscript>

Script non obstrusif permettant d'afficher un élément en cliquant sur un lien. L'élément restera affiché si javascript est désactivé :

[html]
<html lang="fr">
<head>
...
<style type="text/css">
.masquer{
display:none;
}
.afficher{
display:block;
}
</style>

<script type="text/javascript">
function lienafficher(){
document.write('<a href=\"javascript:afficher()\">Afficher le bloc<\/a>');
}

function afficher(){
document.getElementById("exemple2").className="afficher";
}

function masquer(){
document.getElementById("exemple2").className="masquer";
}
</script>

</head>

<body>

<script type="text/javascript">
lienafficher();
</script>
<div id="exemple2">
mon contenu à afficher
</div>

<script type="text/javascript">
masquer();
</script>

</body>
</html>

Par ailleurs, Accessiweb consacre 4 critères aux alternatives au javascript.

Une nouvelle version d'Accessiweb (Accessiweb 1.1) vient de voir le jour avec beaucoup de nouveautés. Matthieu Faure, qui a participé à l'élaboration de cette nouvelle mouture, nous en dit plus sur son blog : AccessiWeb 1.1 c'est parti !

Le blog de Kinoa fait un petit topo sur l'accessibilité d'un site web en 10 points : 10 astuces pour améliorer l’accessibilité de votre site Web.

Une jolie infographie illustre ces 10 points.

1. Séparer la mise en forme du contenu.
2. Prévoir des alternatives aux Scripts. Une page HTML doit être parfaitement lisible lorsque les feuilles de styles sont désactivées.
3. Proposer des alternatives textes.
4. Proposer des formats alternatifs en téléchargement.
5. Eviter d’ouvrir des liens dans une nouvelle fenêtre.
6. Eviter les frames.
7. Proposer systématiquement un plan du site et un moteur de recherche.
8. Proposer des titres explicites à vos pages.
9. Vérifier les contrastes de vos couleurs.
10. Utiliser les technologies du W3C.

Le site voyages-sncf.com vient d'être refondu. Cette refonte ne parvient pas à satisfaire tout le monde comme l'atteste ce billet sur TechCrunch. Toujours est-il que l'accessibilité semble être au cœur des préoccupations de l'équipe en charge du site : Comment Voyages-sncf.com a travaillé son accessibilité sur 01net.com

Et oui, le RGAA refait sa réapparition, son adresse : http://rgaa.dgme.fr/ Merci à Elie Sloïm pour cette nouvelle qui nous réchauffe le cœur :-)

Nacha De Winne a eu l'amabilité de me signaler l'existence d'un site dédié à l'accessibilité : mindonwave.org

Ce site a pour ambition d'être un centre de ressources sur l'accessibilité du Web en Belgique.

En voici les rubriques :

• Accueil
• Actualités
• Agenda
• Contexte
• Acteurs
• Interviews
• Litterature
• Liens

Vous pourrez voir que ce site est une mine de renseignements sur l'accessibilité du web et je tire mon chapeau à leurs auteurs ;)

Le site Access-Key propose des tutoriels vidéo sur l'accessibilité.

Ces vidéos ont l'avantage de nous montrer concrétement des utilsateurs handicapés confrontés à différentes difficultés lors d'une navigation web. Les vidéos nous montrent dans une deuxième partie comment l'intégrateur web peut modifier son site pour résoudre ces problèmes.

5 tutoriels video sont pour l'instant disponibles :

1. L’accessibilité des tableaux
2. Les alternatives textuelles aux images
3. Déclarer la langue dans une page Web
4. Des liens hypertextes compréhensibles
5. Des formulaires accessibles

Le site Access-Key propose des tutoriels vidéo sur l'accessibilité.

Ces vidéos ont l'avantage de nous montrer concrétement des utilsateurs handicapés confrontés à différentes difficultés lors d'une navigation web. Les vidéos nous montrent dans une deuxième partie comment l'intégrateur web peut modifier son site pour résoudre ces problèmes.

5 tutoriels video sont pour l'instant disponibles :

1. L’accessibilité des tableaux
2. Les alternatives textuelles aux images
3. Déclarer la langue dans une page Web
4. Des liens hypertextes compréhensibles
5. Des formulaires accessibles

Les 15, 16 et 17 novembre 2007 a eu lieu le Paris Web 2007, le grand rendez-vous français de la qualité, de l'accessibilité et du design web. Les vidéos sont désormais disponibles :

http://videos.paris-web.fr/

• Les enjeux de la production web

Samuel Latchman nous présente son expérience dans la réalisation de contenus web et l’organisation du travail. Après un bref aperçu des métiers, des délais et des contraintes, nous abordons la standardisation des méthodes de travail et des compétences. Avec des études de cas concrets et des exemples, nous voyons quelles techniques jouent sur la qualité finale. 1ère conférence du jeudi 15/11/2007.

Les diapositives de la présentation au format pdf

• Utilisateurs et décideurs : à hue et à dia !

Myriam Lorant montre les différences de points de vue entre les utilisateurs et les décideurs à l’origine de la demande. Joindre les deux est un travail à plein temps. Myriam nous donne des pistes de réflexions ainsi que des solutions concrètes. 2e conférence du jeudi 15/11/2007.

• Et maintenant, qu'est-ce qu'on met dedans ?

Michèle Pedinielli élargit la problématique pour parler des contenus eux-mêmes. "Du contenu". Certes. Mais pour qui ? Pour quoi faire ? A quelles conditions ce contenu devient de l’information utile et utilisée ? Quelques questions et quelques pistes de réponses autour de la place de l’éditorial dans un site web. 3e conférence du jeudi 15/11/2007.

Les diapositives de la présentation au format pdf

• Le référentiel général d’accessibilité des administrations

Dans une première partie, Pascal Souhard nous donne un aperçu global du référentiel et de sa mise en œuvre vu de l’intérieur. archives : Le RGAA (première partie) Dans une seconde partie, Elie Sloïm (remplaçant Laurent Denis) et Aurélien Levy nous montrent le RGAA d’un point de vue technique : ses implications et comment s’y conformer. 4e conférence du jeudi 15/11/2007.

• Accessibilité des vidéos et des sous-titres

Jean Louis Carvès intervient pour présenter l’état de l’art sur l’accessibilité vidéo. Nous y abordons la question des sous-titres, leur inclusion, et les résultats obtenus. 5e conférence du jeudi 15/11/2007.

• Futur du HTML, où en est-on ?

Pour clôturer la journée, Daniel Glazman finit sur HTML, le langage utilisé pour développer toutes nos pages web. Ce langage est en pleine effervescence et une cinquième version est en cours d’élaboration. Dernière conférence du jeudi 15/11/2007.

Les diapositives de la présentation au format html

• Accessibilité des contenus PDF et Flash

Jugé à tort ou à raison comme le nec plus ultra des formats dynamiques, Flash impose depuis toujours d’importants problèmes fonctionnels aux personnes handicapées. Les promesses de Macromedia (Adobe) laissent croire que cette sombre époque est enfin révolue. L’un des formats les plus populaires sur le Web après HTML, PDF a très mauvaise réputation auprès des internautes ayant des limitations fonctionnelles. Ses détracteurs racontent même que les efforts déployés par Adobe depuis des années pour améliorer l’accessibilité du format ne portent pas leurs fruits. Qu’en est-il vraiment ? Denis Boudreau nous présente l’état de l’art sur ces technologies et un récapitulatif concernant leur accessibilité réelle. 1ère conférence du vendredi 16/11/2007.

Les diapositives de la présentation au format html

• Multilinguisme web et problématiques associées

Le Web nous débarrasse de l’espace et des frontières géographiques. On se retrouve en contact avec des personnes provenant des quatre coins de la planète, et en pratique, les frontières les plus fortes sont linguistiques. Stephanie Booth nous montre où le web nous met des bâtons dans les roues et comment prendre en compte les problèmes qui ne manquent jamais de survenir. 2e conférence du vendredi 16/11/2007.

• Ajax et accessibilité

AJAX tend à devenir une des technologies incontournables des applications web. Son utilisation pose pourtant de sérieuses questions d’ergonomie et d’accessibilité. Michel Hoël nous fait un résumé et partage son expérience sur le sujet. 3e conférence du vendredi 16/11/2007.

• Successful teams use web standards!

Chris Heilmann anime la seule conférence en anglais de ces deux jours. Nous y abordons la mise en œuvre des standards et normes du Web dans les équipes de développement. 4e conférence du vendredi 16/11/2007.

• Bonnes pratiques du Web mobile

La dernière conférence se détache un peu du reste pour nous parler du Web mobile. C’est Dominique Hazaël-Massieux, du W3C, qui nous en présente les bonnes pratiques et nous introduit à ce type d’accès un peu particulier.

Les diapositives de la présentation au format html

• Table ronde

La journée se termine par une table ronde avec l’ensemble des intervenants. C’est l’occasion d’aborder des sujets qui vous tiennent à cœur, de dépasser les points de vue présentés lors des conférences et de provoquer quelques débats. Clôture de la partie "Conférences" de l'édition 2007.

Les diapositives en divers formats (PDF, Powerpoint, Slideshare, OpenDocument…) et les enregistrements audio sont aussi disponibles :

http://2007.paris-web.fr/Presentations-des-intervenants

quelques billets qui reviennent sur le Paris Web 2007 :

• Paris Web 2007 : J’y étais !
• Paris Web vu par un étudiant (1/12)
• Paris Web vu par un étudiant (2/12)
• Paris Web vu par un étudiant (3/12)
• Paris Web vu par un étudiant (4/12)
• Paris Web vu par un étudiant (5/12)
• Paris Web vu par un étudiant (6/12)
• Paris Web vu par un étudiant (7/12)
• Paris Web vu par un étudiant (8/12)
• Paris Web vu par un étudiant (9/12)
• Paris Web vu par un étudiant (10/12)
• Paris Web vu par un étudiant (11/12)
• Paris Web vu par un étudiant (12/12)
• Paris Web 2007 : du Paris, du Web et des Grèves
• Paris Web 2007 : premiers retours
• Paris Web 2007, c'est fini !
• Paris Web 2007, c'est fini
• Compte-rendu de Paris Web 2007
• Retour de Paris Web
• Web, Paris, grèves…
• Paris Web 2007 - Les ateliers
• ces types de Paris-Web sont complètement allumés
• Paris Web : Conférences - 1ere journée
• Paris Web 2007 (Jour 1/2)
• Paris Web 2007, encore mieux qu'en 2006

Le document Petit guide à l’usage des hôteliers–restaurateurs et de leurs webmestres se propose de donner aux hôtels-restaurants des conseils pratiques et réalistes, pour rendre plus accessible leur site web, en particulier aux publics handicapés et vieillissants.

En plus des conseils valables pour tous les sites web, des conseils spécifiques aux hôtels-restaurants sont donnés :

• indiquer sur le site le label "Tourisme & Handicap" si l'établissement le possède,
• mettre les menus du restaurant à disposition pour qu'ils puissent être imprimés en braille,
• indiquer les conditions d'accueil des chiens guides,
• etc...

Le guide a classé les conseils par public :

• Recommandations générales pour tous les publics et handicaps,
• Recommandations pour les handicaps visuels,
• Recommandations pour les handicaps moteur,
• Recommandations pour les handicaps auditifs,
• Recommandations pour les handicaps cognitifs.

A la fin du guide un tableau permet de "checker" les points à ne pas oublier.

Le guide se termine par une liste de références sur l'accessibilité du web à consulter.

Ce guide a été conçu par Le département "Conseil, Recherche et Innovation" du Greta du Velay avec la collaboration d'experts en accessibilité.

Ce guide a le soutien de la Commission européenne, mais il ne reflète pas nécessairement son point de vue.

Le guide m'a paru complet et clair. Il s'agit d'une bonne initiative et j'espère qu'il sera largement diffusé et surtout pris compte.

Via le billet Un guide sur l'accessibilité des sites hôteliers de Sébastien Billard.

456 Berea Street nous fait la liste des améliorations en terme d'accessibilité sur la nouvelle version du système d'exploitation de Apple : Mac OS X 10.5 Leopard improves accessibility.

Frédéric de Villamil dans son carnet nous donne une traduction de la liste et la commente : Mac OS X 10.5 Léopard et l'accessibilité.

• L’ajout d’une nouvelle voix au module de dictée. Bienvenue à Alex.
• Le support natif des claviers en braille.
• Un clavier braille virtuel.
• La possibilité de contrôler VoiceOver via le pavé numérique.
• Une navigation facilitée dans les longs documents et les pages web. Le système peut maintenant lister et sauter de titre en titre, de table en table ou de lien en lien, quand Tarzan ne peut que sauter de liane en liane.
• Hot spots permet de surveiller jusqu’à 10 zones sur un écran et avertit l’utilisateur quand l’une d’elles change.
• Dans les applications accessibles, le drag and drop est possible à l’aide du seul clavier.
• Enfin, l’accessibilité des applications embarquées a été grandement améliorée.

Il est réjouissant de voir que l'accessibilité n'a pas été oublié par Apple dans la nouvelle mouture de son système d'exploitation.

Après avoir lu l'excellent billet de Elie Sloïm : Transcrire les contenus audiovisuels, je me suis dit que si un jour un service web du type YouTube voyait le jour et qu'il donnait la possibilité aux utilisateurs de fournir la transcription textuelle des vidéos, voire les traductions, cela serait alors un grand pas vers des vidéos enfin accessibles.

Et là, je viens de découvrir le site dotSUB.com (encore en bêta), via le billet Des vidéos accessibles avec Dotsub.com sur le blog Webqualité.

Le service permet ainsi classiquement de uploader des vidéos, d'y mettre un titre, un commentaire. Mais la grande nouveauté, c'est de pouvoir en fournir une transcription textuelle via un système de sous-titre, et en plus de pouvoir traduire ces sous-titre dans d'autres langues. Et bien sûr, ces 2 fonctionnalités sont possibles sur les vidéos des autres utilisateurs.

Ce que j'ai trouvé dommage c'est que la transcription n'apparaisse que sous forme de sous-titres. Pourquoi ne pas prévoir un encart sous la vidéo, avec tout le texte de vidéo. Ce texte, si il est visible directement dans le code html, peut permettre encore une meilleure accessibilité du contenu de la vidéo il me semble. Le service étant encore en version bêta, on peut espérer que cela possible dans le futur.

En tout cas, ce service fait avancer selon moi dans le bon sens l'accessibilité de la vidéo.

De plus, le système de traduction va je pense maximiser le potentiel des vidéos. De nos jours, beaucoup d'évènements très intéressant sont filmés comme les conférences, mais la barrière de la langue empêche souvent de profiter pleinement de ces vidéos.

Un billet concernant l'accessibilité au Royaume-Uni (Accessibility Ultimatum Proposed for UK Government Websites) a fait réagir Elie Sloïm sur son blog : Des sanctions pour les sites publics anglais non accessibles ?

Vouloir rendre obligatoire l'accessibilité de sites internet du service public est une chose, Mettre en oeuvre de cette obligation en est une autre. Peut-être faudrait t'il parler avant tout d'obligation de moyens plutôt que d'obligation de résultat, un peu comme les medecins qui sont tenus à tout mettre en oeuvre pour soigner leurs patients, mais qui ne s'engagent pas à les guérir, ni à un certain seuil de guérison.

Lors de la dernière conférence "Adobe Max Europe 2007" qui a eu lieu à Barcelone du 15 au 18 octobre, Mat May est venu faire une présentation autour du thème de l'accessibilité des applications développées avec Adobe Flex. Le site Flash xpress nous propose une vidéo de cette présentation : Développer des applications accessibles avec Flex

La présentation commence par expliquer les bénéfices de l'accessibilité puis, les éléments à prendre en compte lors du developpement :

• Coder l'application en rendant l'application exploitable via clavier
• Utiliser des éléments de code en Flex et Flash qui permettent de rendre accessible l'application (26 éléments sont cités)
• Utiliser MSAA (Microsoft Active Accessibility) pour rendre exploitable l'application par les lecteurs d'ecran
• Utiliser les solutions de sous-titrage (à base de xml) pour les vidéos
• Fournir à l'utilisateur une aide sur l'utilisation des dispositifs spécifiques qui ont été developpés en vue d'améliorer l'accessibilité
• Faire appel à des experts en accessibilité
• Intégrer l'expérience utilisateur pour éprouver la mise en place de l'accessibilité

Le site pompage nous propose un article : Améliorer l’accessibilité par la typographie. Il s'agit de la traduction par Goulven Champenois d'un article de Joe Dolson : Improving Accessibility through Typography.

Je commence à réfléchir depuis un bon moment à l'intégration des notions d'accessibilité dans les projets web. J'ai donc commencé à chercher quelle base de travail utiliser, et mon choix s'est porté sur le Référentiel Général d’Accessibilité pour les Administrations (RGAA) pour plusieurs raisons :

• Le jour où un décret d'application de la loi n°2005-102 de février 2005 sera mis en place pour rendre obligatoire l'accessibilité des sites web du secteur public, c'est vraisemblablement ce document qui sera pris en référence, et qui devra être suivi par les agences web qui réaliseront les sites web du secteur public. Donc, utiliser déjà le RGAA, c'est anticiper le futur, et pouvoir assurer à ses clients qu'ils n'auront pas à complètement refondre leur site quand le décret sera adopté, même si le RGAA aura peut être évolué d'ici là.
• Le document prend comme référence le WCAG 1.0, et donc suivre le RGAA c'est suivre les recommandations du W3C en terme d'accessibilité.
• Il s'agit du document le plus récent à ce jour (par rapport aux critères AccessiWeb) et il prend en compte d'autres recommandations que WCAG : UWEM et AERT.
• Le document fourni des explications et des exemples pour aider à la bonne compréhension des directives.

Le champ d'application comme filtre

Les tests proposés dans le RGAA ont la particularité d'indiquer clairement le champ d'application du test. Pour le test 1.1.1 Présence de l'attribut alt par exemple, il est indiqué que le champ d'application se limite aux éléments img, area, input type='image' et applet. Je me suis rendu compte qu'un champ d'application pouvait être commun à plusieurs tests. Si nous prenons par exemple l'élément fieldset, il fait partie du champ d'application du test 3.3.2, du test 12.3.2 et du test 12.3.3. Donc, j'ai eu l'idée de filtrer tous les tests, pour obtenir une fiche par élément, ce qui permettrait de faire en une fois tous les tests correspondants à cet élément. Ainsi, j'ai crée chacune de ses fiches sous ce modèle :

La colonne WCAG indique le niveau WCAG du test :

• A : Ce qui doit être fait
• AA : Ce qui devrait être fait
• AAA : Ce qui pourrait être fait

La colonne Priorité donne des indications sur le caractère prioritaire du test dans le cadre d'un déploiement dans le temps du RGAA :

• Priorité 1 :
  • année N : Obligatoire
  • année N+1 : Obligatoire
  • année N+2 : Obligatoire
• Priorité 2 :
  • année N : Recommandé
  • année N+1 : Obligatoire
  • année N+2 : Obligatoire
• Priorité 3 :
  • année N : Recommandé
  • année N+1 : Recommandé
  • année N+2 : Obligatoire
• Priorité 4 :
  • année N : Recommandé
  • année N+1 : Recommandé
  • année N+2 : Recommandé

La colonne Points de contrôle indique le numéro du point le contrôle auquel est lié le test. Un lien hypertexte renvoie vers la page web de la fiche RGAA du point de contrôle. Il est très utile, voire indispensable de consulter cette fiche pour mieux comprendre, par l'explication et les exemples fournis, comment faire le test.

La colonne Tests donne le titre du test. Un lien hypertexte renvoie vers la page web de la fiche RGAA du test.

La colonne champ d'application indique le champ d'application du test, que j'ai élargi en indiquant si cela concernait le code html ou le code css, et en donnant des précisions supplémentaires. Un lien hypertexte sur le mot champ d'application renvoie vers la première feuille du classeur Excel, qui forme la liste de tous les éléments à tester.

La colonne vérification fait apparaître la vérification qui doit être faite à travers le test. J'ai modifié sensiblement le texte à chaque fois pour préciser le champ d'application, ainsi j'ai par exemple remplacé le texte "Si l'un des éléments mentionnés dans le champ d'application est présent dans la page, poursuivre le test, sinon le test est validé" par le texte "Si la balise <fieldset></fieldset> est présente dans la page, poursuivre le test, sinon le test est validé."

Je me suis donc retrouvé avec une feuille par élément. Pour pouvoir facilement consulter les feuilles j'ai crée une feuille qui se trouve au début du classeur avec un tableau qui liste l'ensemble des éléments sous cette forme :

Un lien hypertexte sur chacun des éléments renvoie vers la feuille du classeur Excel qui liste tous les tests à effectuer pour l'élément concerné.

Pour ne pas surcharger un seul classeur, j'ai crée 3 classeurs :

• 1-html-checklist.xls qui regroupe tous les éléments à tester trouvables dans un document html,
• 2-css-checklist.xls qui regroupe tous les éléments à tester trouvables dans un document css,
• 3-divers-checklist.xls qui regroupe tous les éléments à tester que je n'ai pas pu classer dans les 2 précédents classeurs.

Les versions Excel et OpenOffice se trouve dans ce dossier. Les versions OpenOffice sont justes des conversions des versions Excel mais elles fonctionnent.

Pourquoi ai-je voulu réorganiser les tests du RGAA par champ d'application ?

Je veux pouvoir faire en sorte que les tests sur un site web puisse se faire de manière linéaire, ligne à ligne, effectuer les tests sans avoir ensuite à revenir en arrière dans le code pour faire les autres tests. C'est une vision peut être trop orienté code des tests du RGAA, j'en ai conscience.

Pour finir, je tiens à préciser que tout ce que je viens de présenter ici n'a rien d'officiel ni de définitif, et qu'il y a peut-être des inexactitudes dans mes tableaux. Il s'agit avant tout de travaux en cours issus de réflexions personnelles sur le RGAA, réflexions non achevées ;-)

Si vous avez des remarques sur ma démarche, je suis tout ouïe :)

Big.com est un moteur de recherche proposé par Yahoo, qui est censé s'adresser au personnes ayant des problèmes de vue. Du coup, on se retrouve avec une page d'accueil et de résultat avec une taille de police très grande :

Le gros défaut du site c'est que toute la moitié droite de la page est occupé par les liens sponsorisés, ce qui nuit à la lisibilité de la page de résultat, la lisibilité qui est normalement le credo de ce site : "The most readable results on the web."

Personnellement, je me pose la question de l'intérêt d'un tel site, par rapport à Yahoo Search qui me parait disposer d'une page de résultats plus lisible (et surtout moins pollué) que celle de Big.com lorsque l'on agrandit la police de caractère avec le raccourci clavier Ctrl et +.

Accesstech est une nouvelle liste de diffusion francophone dédiée à l'accessibilité du web, d'un point de vue technique.

Je vous invite à lire le billet de lancement, ainsi que de vous inscrire sur cette liste bien sûr !

Fred Cavazza prépare la 3ème édition de la Journée Mondiale de l’Utilisabilité 2007 qui se tiendra le jeudi 8 novembre de 9 H à 12 H 30 dans les locaux de Microsoft à Paris.

L'utilisabilité aura aussi sa journée en Belgique : Usability Day Belge - Le programme !

Pour vous rendre compte de ce que peut être l'utilisabilité appliqué au sites web, je vous conseille la lecture (en anglais) de 30 Usability Issues To Be Aware Of sur Smashing Magazine.

Innovablog s'est attelé à en faire une traduction en français : Accessibilité, ergonomie et utilisabilité : 30 points clés

edit : je viens de trouver une traduction plus complète sur Référencement, Design et Cie : 30 concepts-clés de l'utilisabilité

Mise à jour du 17 novembre 2007

• Introduction

• Intervention de Frédéric Gaillard sur le thème de l'expérience utilisateur

• Intervention de Frédéric Cavazza sur les tendances de l'utilisabilité en 2007

• Intervention d'Elie Sloîm sur le thème de la qualité web et de l'accessibilité

• Intervention de Guillaume Brachon sur les interfaces sociales

• Intervention de Laurent Goffin sur les réseaux sociaux et l'utilisabilité

• L'utilisabilité : définition et place dans un projet web

• Utilisabilité et qualité web

• L'utilisabilité, emploi présent et perspectives d'avenir

• Quelques réactions...

• Les vidéos et supports de présentation des intervenants
• Compte-rendu (rapide) de la Journée Mondiale de l’Utilisabilité 2007
• World Usability Day - Compte rendu (1/2)
• World Usability Day - Compte rendu (2/2)
• World usability (yester)day
• Journée Mondiale de l'Utilisabilité 2007, et après ?