"accessibilite" via neolao in Google Reader

BritoWeb : Référentiel Accessiweb 2.0 : parution officielle

2009-12-17T17:10:00Z

Le référentiel Accessiweb (celui concernant les sites Web), maintenu par l'association Braillenet évolue dans une nouvelle version, la 2.0, qui vient de paraître officiellement.

Cette nouvelle version est motivée par la publication, l'année dernière, des WCAG 2.0, la nécessité de les faire comprendre et de permettre la vérification de la conformité des sites Web à cette nouvelle version, ainsi que par la parution du RGAA 2.2, qui entraîne un besoin de cohérence avec ce dernier.

Par rapport à la précédente version 1.1, Accessiweb 2.0 maintient la répartition des critères et tests en 13 thématiques, ainsi que les trois niveaux d'accessibilité Bronze, Argent et Or (qui équivalent, respectivement, aux niveaux de conformité A, AA et AAA des WCAG 2.0). De même, on retrouve les deux listes : la liste générale (comprenant les critères, formulés de façon à être compris du plus grand nombre) et la liste déployée (comprenant les tests, dont la formulation emploie un vocabulaire plus technique), ainsi qu'un glossaire expliquant les termes spécifiques employés dans l'intitulé des critères et des tests.

Le principal changement réside dans le nombre de critères et de tests, qui augmente sensiblement : le référentiel Accessiweb 2.0 ne comporte pas moins de 131 critères (81 de niveau Bronze, 20 de niveau Argent et 30 de niveau Or) et de 300 tests (196 de niveau Bronze, 47 de niveau Argent et 57 de niveau Or).

Enfin, le référentiel Accessiweb 2.0 peut être utilisé dans le cadre d'une procédure de certification de conformité d'un site ou d'un service Web aussi bien aux WCAG 2.0 qu'au RGAA 2.2. Autrement dit, le référentiel Accessiweb 2.0 peut être utilisé pour évaluer un service en ligne de l'État, d'une collectivité territoriale ou d'un établissement public qui en dépend (à ceci près qu'un service en ligne évalué qui réussit l'examen d'Accessiweb 2.0 doit être soumis à quelques tests supplémentaires s'il veut être pleinement conforme au RGAA 2.2, les tests étant ceux du RGAA qui divergent d'Accessiweb).

Liens utiles

Le guide Accessiweb sera mis à jour vers la fin du premier semestre 2010.

BritoWeb : Nouvel outil de vérification du contraste des couleurs selon les WCAG 2.0

2009-12-12T21:09:00Z

Cela fait un an que les WCAG 2.0 ont acquis le statut de recommandation (qui fut ensuite traduite en français). Bon nombre d'évolutions et de changements se présentent par rapport aux WCAG 1.0, dont l'algorithme utilisé pour évaluer le contraste des couleurs.

Le nouvel algorithme utilisé ne se base plus sur les notions de différence de couleur et de différence de luminosité, mais sur la notion de ratio de contraste, lui-même basé sur la luminosité relative des couleurs.

Afin de faciliter l'évaluation du contraste des couleurs dans l'esprit des WCAG 2.0, un nouvel outil de vérification de contraste des couleurs est désormais disponible (celui basé sur l'algorithme préconisé dans les WCAG 1.0 restera toujours en ligne).

Le principe reste le même : vous saisissez le code hexadécimal à six chiffres (sans le dièse initial) respectif de la couleur de premier-plan et de celle d'arrière-plan que vous souhaitez utiliser dans vos feuilles de style ou dans vos maquettes graphiques. Une fois le formulaire soumis, le verdict tombe, qui indique si le contraste est suffisant selon le contexte : texte agrandi ou pas, texte en gras ou pas, contraste minimum (niveau AA des WCAG 2.0) ou amélioré (niveau AAA des WCAG 2.0).

Les notations raccourcies du code hexadécimal, lorsqu'elles existent (par exemple, #369 pour #336699), sont autorisées. En revanche, les mots-clés de couleur utilisés en CSS ne peuvent être utilisés, ni le code décimal (par exemple : 128, 128, 255). Pour rappel, les mots-clés de couleur en CSS correspondent aux codes hexadécimaux suivants :

maroon : #800000,
red : #ff0000 (ou #f00),
orange : #ffa500,
yellow : #ffff00 (ou #ff0),
olive : #808000,
purple : #800080,
fuchsia : #ff00ff (ou #f0f),
white : #ffffff (ou #fff),
lime : #00ff00 (ou #0f0),
green : #008000,
navy : #000080,
blue : #0000ff (ou #00f),
aqua : #00ffff (ou #0ff),
teal : #008080,
black : #000000 (ou #000),
silver : #c0c0c0,
gray : #808080.

ACTF ( Accessibility Tools Framework ) :Évaluation et amélioration de l’accessibilité Flash & HTML

2009-12-11T15:43:52Z

Je viens tout juste de découvrir ACTF, un plugin pour eclipse qui permet d’évaluer et d’améliorer l’accessibilité des applications web pour les personnes handicapées, autrement dit, d’augmenter l’accessibilité aux contenus du web.

Téléchargement du plugin ACTF »
Outre une perspective complète pour Eclipse, ACTF propose aussi les fonctionnalités de cette perspective dans différentes applications :

ACTF Accessibility Internet Browser for Multimedia (aiBrowser) »
« L’utilisation de contenu multimédia a considérablement augmenté au cours des dernières années, mais les gens ayant peu ou pas de vision n’ont pas été en mesure de profiter pleinement des avantages de ces avancées. aiBrowser offre, aux personnes ayant une déficience visuelle, un niveau de contrôle comparable à une personne voyante, à l’aide d’une souris. Par exemple, tout en regardant une vidéo en continu, les personnes ayant une déficience visuelle peuvent maintenant sélectionner le bouton de lecture, en appuyant simplement sur une touche de raccourci prédéfinie, au lieu de chercher dans le contenu des boutons…
Les utilisateurs peuvent également ajuster le volume d’une source individuelle, afin d’identifier et d’écouter les différentes sources sonores, sans perdre à l’écran les logiciels de lecture, à cause du son d’une vidéo. Si un créateur de contenu veut fournir un récit voix d’une vidéo, il peut écrire un script texte comme un morceau de métadonnées; l’outil ajoute les descriptions audio en utilisant le moteur text-to-speech. Les futurs plans pour étendre cette technologie consiste à permettre un contrôle flexible de la vitesse audio, ainsi que l’apport de ce travail à un projet de développement open-source. Cette contribution permettra d’accélérer le développement et l’adoption d’outils qui rendent sur le Web un contenu multimédia accessible aux personnes malvoyantes. »
ACTF aDesigner »
« aDesigner est un simulateur de handicap qui aide les concepteurs à s’assurer que leur contenu et les applications sont accessibles et utilisables par les malvoyants.
Les navigateurs vocaux et lecteurs d’écran lisent à haute voix le texte des pages Web et sont utilisés par des personnes ayant une déficience visuelle. Cependant, ces appareils sont moins efficaces avec certains types de contenus, tels que les applications extrêmement graphique. Les développeurs Web peuvent utiliser aDesigner pour tester l’accessibilité et l’utilisabilité des pages Web pour basse vision et les personnes aveugles.

aDesigner permet également aux utilisateurs de vérifier l’accessibilité des documents ODF et le contenu Flash. »
ACTF Accessibility Probe »
Accessibility Probe (AccProbe) est une application RCP (Eclipse Rich Client-Produit) qui fournit une vue sur le Microsoft Active Accessibility (MSAA) ou sur la hériarchie IAccessible2 d’une demande en cours d’exécution ou d’un document rendu et des propriétés des objets accessibles de cette demande ou le document. Il peut aussi servir de moniteur d’événements pour le suivi des événements déclenchés par ces objets accessibles. Il est destiné à combiner les fonctionnalités d’outils comme Inspect32 de Microsoft, AccExplore, et AccEvent dans une application afin de tester l’accessibilité et le débogage. »

Voyons maintenant un exemple d’utilisation dans Eclipse :

Une fois le plugin installer, vous devriez pouvoir sélectionner une de ce perspectives :
     - HTML Accessibility
     - Flash Accessibility
     - GUI Accessbility

Testons le site w3c ( http://www.w3.org ).

Dans la perspective HTML Accessibility, nous pouvons simuler l’affichage pour une personne non voyantes :

Avec le résumé de la simulation :

L’affichage fournit au survol le nombre de seconde qu’il faut au navigateur vocal pour atteindre le passage, ainsi les détails et conseils pour améliorer l’accessibilité pour les personnes non voyante :

ou simuler l’affichage pour une personne mal-voyante :

Avec le résumé de la simulation :

Les détails et conseils ( « Foreground and background colors are too close ») pour améliorer l’accessibilité pour les personnes mal-voyante :

La perspective Flash Accessibility regroupe le navigateur, ainsi que la perspective GUI Accessibility :

Le panel « GUI Summary » permet l’affichage des textes accessibles, ainsi que la possibilité de navigation sans cliquer dans le navigateur. Simpltement bluffant ! Je n’ai pas poussé les tests extrêmement loin, mais on peut d’ore et déjà se rendre compte des problèmes d’affichage de son flash ( pas de nom pour les boutons quand ils n’ont pas de textes associés… ).
Le panel « GUI Report » permet d’afficher les améliorations à apporter pour rendre un peu plus accessible son application.

En résumé, que dire ? Tellement ! Ayant été largement sensibilisé à l’accessibilité (niveau bronze) dans une ancienne société, je suis agréablement surpris de ce plugin, qui en plus d’être extrêmement complet est open-source (en espérant qu’il le reste, c’est pour la bonne cause). Je suppose que des outils sont apparus ces dernières années pour évaluer et améliorer l’accessibilité des sites HTML (c’était une de mes frustrations, à l’époque ou je faisais de l’accessibilité, de ne pas pouvoir simuler l’affichage pour les personnes souffrant de handicaps), mais celui combine vraiment tous les outils nécessaires, y compris celui d’évaluation des applications Flash, un grand pas en avant. A conseiller, à tester, à garder sous le coude en permanence…

A l’origine de ce post : How Accessible is your Flash? »

Adresse Remote Site »
ACTF Downloas »
Accessibility Tools Framework »

Un module de lecture braille portable

2009-12-09T05:38:54Z

En plus d’être très design, ce module s’avèrera utile pour de nombreuses personnes aveugles, et ayant besoin de dispositifs de lecture braille, pour communiquer sur les nouveaux réseaux.

Ce voulant un complément au appareil mobile, le Squibble du designer Andrew Mitchell sera une interface braille, auditive et visuelle (hauts contrastes) à tout appareil mobile de communication ou autre par texte. Plus qu’un concept, l’appareil est selon les dires d’Andrew déjà bien avancé, utilisant 779 moteurs ultrasonics pour faire “sortir” des picos LED et offrir le relief nécessaire pour une lecture braille. Il communique via Bluetooth.

via thedesignblog

BritoWeb : Un tableau de données lu comme un tableau de mise en forme, et inversement

2009-12-03T09:05:00Z

En toute logique, un tableau de mise en forme codé en tant que tel est lu comme tel (avec linéarisation et sans aucune indication d'association de cellules) par un lecteur d'écran, qui lira un tableau de données correctement codé (avec les éléments th et les attributs appropriés, scope ou id/headers, pour associer les cellules de données aux cellules d'en-tête correspondantes) en prenant soin d'indiquer le nombre de colonnes et de lignes, ainsi que les associations de cellules explicitées.

Il se trouve que Jaws peut parfois lire un tableau de données comme si c'était un tableau de mise en forme, et inversement.

Dans un billet publié hier sur le blog de WebAIM et initutlé Jaws ate my tables, Jared Smith rapporte que Jaws ne se base pas sur le code source du tableau (notamment en repérant la présence d'éléments th) pour savoir s'il a affaire à un tableau de données ou à un tableau de mise en forme.

Pour que Jaws considère un tableau comme un tableau de données, il faut que ce tableau ait au moins 2 lignes et 2 colonnes et, en même temps, au moins 4 cellules occupant une surface comprise entre 200 et 16 000 pixels au carré. Autrement dit, si un tableau de données comporte une cellule avec beaucoup de texte ou est agrandi par simple agrandissement de la taille de police, Jaws pourra le traiter comme un tableau de mise en forme. À l'inverse, si un tableau de mise en forme comporte au moins 4 cellules, réparties sur au moins 2 lignes et 2 colonnes, qui tiennent dans une surface comprise entre les valeurs indiquées plus haut, il sera lu par Jaws comme si c'était un tableau de données. Pour mieux nous en convaincre, Jared Smith montre deux exemples de tableaux, l'un de données et l'autre de mise en forme, qui ne sont pas lus correctement par Jaws.

En attendant que Freedom Scientific résolve ce dysfonctionnement, Jared Smith invite les utilisateurs de lecteur d'écran à regarder du côté des lecteurs d'écran alternatifs qui, comme NVDA, prennent en charge les tableaux plus convenablement.

Bref, certains seraient tentés, je parie, de penser comme cet utilisateur aveugle commentant le billet de Jared Smith : As a blind user, I find Jaws is like IE6 (En tant qu'utilisateur aveugle, je trouve que Jaws est comme IE 6).

AccessiBlogue : Accessibilité et CRTC 2009-430 : des précisions sur les obligations

2009-11-27T19:50:45Z

Le 8 octobre dernier, je vous faisais part de la Politique réglementaire CRTC 2009-430 du Conseil de la radiodiffusion et des télécommunications canadiennes (CRTC) qui amène celle-ci à prendre position dans le dossier de l'accessibilité du Web pour les personnes handicapées. Par l'adoption de cette politique, le CRTC impose un code de conduite aux fournisseurs de services de télécommunication afin de les obliger à assurer aux citoyennes et citoyens du Canada un accès à des contenus informationnels (...)

L’interopérabilité et les standards ouverts menacés en Europe ?

2009-11-25T14:11:01Z

L'EIF, le référentiel d'interopérabilité européen est-il miné par les pressions du lobby du logiciel propriétaire ? La version 2 du document, en préparation, viderait sciemment de son sens les notions d'interopérabilité et de standards ouverts.

Survol des hyperliens

2009-11-14T19:08:23Z

Éric a récemment abordé le cas des boutons activés, je prends le relais et je m’interroge cette fois sur le survol des liens.

La convention veut que les liens soient identifiés par le soulignement de ceux-ci et je reste donc dans ce cas classique. Bien souvent ensuite (dans le but de signaler l’interaction) ce soulignement sera retiré au survol.

<style type="text/css">
    a:focus,
    a:hover
    {
        text-decoration:none;
    }
    a:active
    {
        outline:none;
    }
</style>

Remarquez au passage :

que je complète mon sélecteur pour le cas d’une navigation au clavier (j’y reviendrai plus tard) ;
la définition de l’état actif, trouvée via ce très bon billet sur la suppression de l’outline.

Je ne sais pas pour vous, mais j’ai tendance à trouver cette technique (pourtant répandue !) contre-intuitive. C’est comme si le lien « disparaissait » au survol, et que du coup il n’était plus possible (en apparence) de cliquer.

J’aurais tendance à préférer tout autre mise en forme au survol. Comme par exemple un changement de couleur. On pourrait même reprendre celle des liens visités tiens…

<style type="text/css">
    a
    {
        color:#1C6280;
        background-color:inherit;
    }
    a:hover,
    a:focus,
    a:visited
    {
        color:#1C6280;
        background-color:inherit;
    }
    a:active
    {
        outline:none;
    }
</style>

J’aimerais lire vos avis et vos arguments, je n’arrive pas à trancher cette question.

Question bonus : les sélecteurs enrichis pour les navigations au clavier, ça ne pose pas de souci ? Je pense notamment à une personne qui d’une part survol un lien à la souris, tant en tabulant sur un autre lien en parallèle : il se retrouve alors avec deux liens mis en évidence à la fois.

Journée mondiale de l’utilisabilité – 12 novembre 2009

2009-11-09T22:20:07Z

C’est avec plaisir que l’association Utilisabilité Québec vous invite le 12 novembre prochain, de 18h00 à 20h30, à une série de conférences portant principalement sur la thématique de «l’utilisabilité pour un monde durable».

Nous aurons la chance de recevoir, notamment:

Sandrine Prom Tep, Chaire de commerce électronique RBC Groupe Financier & Julie Saulnier, Bell : «L’évaluation de la qualité d’un site Web en combinant la poursuite oculaire, la réponse physiologique et l’expression spontanée des émotions ressenties»

Jean-Yves Fiset, Système Humains-Machines inc. et chargé de cours à l’École Polytechnique de Montréal : «Utilisabilité et Développement durable : un mariage de convenance? »

Jean-François Boisvert, Desjardins Groupe d’assurances générales : «Les bénéfices reliés a l’utilisation de “UI Frameworks”»

Yannick Roy, Yu Centrik: «Résultats préliminaires d’une étude mondiale sur l’adaptabilité des sites internationaux aux contextes locaux, étude réalisée par les membres de UX Alliance »

De plus, l’Alliance Numérique viendra nous présenter son récent document intitulé «Le guide des meilleures pratiques Web» où l’ergonomie est positionnée en amont du processus de conception.

Un cocktail et un léger goûter vous seront offerts pour l’occasion par nos partenaires Bell (Montréal) et le Cégep de Ste-Foy (Québec).

À Montréal, Québec et Luxembourg. La conférence se tiendra au CRIM de Montréal et sera diffusée en simultané dans les locaux du Cégep de Ste-Foy à Québec. Un clin d’oeil sera fait à la FLUPA, le chapitre franco-luxembourgeois d’UPA.

Gratuit et accessible à tous – Places limitées

S.V.P., hâtez-vous de confirmer votre présence : info[a]utilisabilitequebec.org

Source : Utilisabilité Québec

ARIA et validation : comment faire ?

2009-11-06T15:29:25Z

Stéphane Deschamps me pique la plume. Le sujet se prête mieux au format de ce blog qu’au sien.

Un peu d’histoire

L’idée d’ARIA c’est de permettre de décrire des rôles et des états, pour améliorer l’accessibilité des clients riches. Ainsi on peut légalement avec ARIA faire une case à cocher en image, pourvu qu’on la décrive comme une case à cocher (role="checkbox") et qu’on indique son état, cochée (aria-checked). C’est pratique pour faire des graphismes modernes, tout en permettant de ne pas sacrifier l’accessibilité au seul profit de ceux qui ont des yeux et une souris, pour résumer.

Quand ARIA a été introduit, on ne parlait pas encore de HTML 5 au W3C : c’est XHTML qui prévalait. Or en XHTML une notion fondamentale est celle des espaces de nommage, permettant de rattacher au document courant (dont l’espace de nommage HTML est implicite) des extensions. ARIA bénéficiait donc d’une déclaration dans le document pour permettre à chacun de ses attributs d’être déclaré avec le préfixe aria:. Par exemple le rôle d’un élément s’écrivait aria:checkbox. Facile.

Avec l’avènement de HTML 5 et ses choix différents en termes de formalisme, qui privilégient l’écriture de code avec la syntaxe HTML, ARIA a dû faire machine arrière : tout a été renommé sans espace de nommage. Les deux points des propriétés spécifiques à ARIA ont été remplacés par des tirets : aria:checked devient aria-checked. Certains attributs quant à eux, qui ont du sens même hors du contexte d’ARIA, n’ont carrément pas de préfixe. C’est le cas de role, qui était prévu dans la spécification XHTML 2.

Pour l’accessibilité dans le monde réel, c’est presque une bonne chose : à ce jour, la revue d’écran la plus utilisée (Jaws) ne reconnaît pas les attributs préfixés. J’en ai fait la douloureuse expérience lorsque mon site est passé en XHTML : Jaws ne comprenait pas les attributs xml:lang et les ignorait purement et simplement ! (Il a fallu doubler tous ces attributs avec l’attribut HTML classique lang).

Oui mais voilà : et la validation dans tout ça ?

À ce jour, le validateur du W3C s’appuie sur le DOCTYPE que vous déclarez dans votre code pour vérifier que vous respectez bien sa grammaire. Or dans une spécification ancienne (XHTML 1.1 date de 2001), il n’était évidemment pas prévu d’intégrer des attributs dont on ignorait qu’ils existeraient un jour ! Sans compter que la logique même d’extensibilité du XHTML venait de l’idée qu’on intégrerait tout ça avec des espaces de nommage, donc l’extension était prévue, mais avec un formalisme que le brouillon courant de HTML 5 remet en cause. Bref, nous voilà au pied du mur : faut-il faire du code invalide, ou respecter maniaquement la spécification et trouver des contournements « légaux » ?

Une solution : opter pour du code invalide

La solution simple serait d’opter pour du code invalide. Eric Meyer considère qu’on peut prôner les standards en étant fidèle à l’esprit mais pas toujours à la lettre : c’est ce qu’il appelle standards-oriented.

En l’occurrence, imaginons que j’aie écrit une page conforme et que j’y rajoute des attributs ARIA. Elle devient non-valide, mais j’ignore les erreurs en connaissance de cause parce que je suis un développeur Web avisé, et que je sais que ça ne posera pas de souci aux navigateurs tout en améliorant l’accessibilité pour tous.

Utiliser un attribut HTML existant et manipuler ses valeurs avec JavaScript

La deuxième solution est plus sportive : je crée du code valide, et je profite de JavaScript pour ajouter les attributs qui me manquent.

Cas classique : je repère l’élément via son id (identifiant unique dans la page), et j’ajoute le ou les attributs dont j’ai besoin pour faire de l’ARIA.

Oui mais : tous mes éléments ne sont pas forcément nommés, pourtant je risque d’avoir besoin de nombreux endroits auxquels me raccrocher pour ajouter des propriétés ARIA.

Le plus simple sera alors d’utiliser un attribut HTML, d’en extraire le contenu et de générer les attribut ARIA à partir de là.

Quel attribut choisir ?

J’ai déjà vu des gens utiliser l’attribut rel des liens, par exemple pour faire des popins (rel="popin,450,300" indique qu’à ce lien sera ajouté un comportement JavaScript d’affichage de la popin, et les dimensions de ladite popin). Pour ma part j’en suis très gêné, il me semble qu’il s’agit là d’un détournement assez osé de l’attribut. Par ailleurs, ça ne fonctionne que sur des liens ; il faut donc trouver un attribut plus générique.

En revanche, la bonne idée depuis plusieurs années, c’est tout de même qu’on tente de ne pas mettre de comportement dans le code. On s’appuie sur le DOM pour inventorier les éléments auxquels affecter tel ou tel comportement, souvent en passant par l’attribut class. Pour revenir à notre exemple de popins, il y a quelques années on aurait fait la même chose en popup, en s’appuyant sur la classe : class="popup".

Essayons donc de nous appuyer sur la classe : il nous semble moins nocif d’utiliser cet attribut plutôt qu’un autre.

Quelle méthode ?

Maintenant que nous avons choisi la classe, quelle convention d’écriture adopter pour tous ces attributs ?

Première proposition, utiliser une notation héritée de JSON : class="{role:contentinfo;}". Son intérêt c’est qu’elle est facile à interpréter, et qu’elle sera extensible si nous devons ajouter plusieurs attributs : class="{role:checkbox;aria-checked:true;}". Son gros défaut c’est qu’elle a l’apparence d’une verrue dans le code, sans compter que cette notation ressemble suffisamment à la notation classique des paires propriété / valeur de CSS pour au mieux prêter à confusion chez le développeur moins au fait que vous, au pire faire tousser un navigateur dont le parseur de code y reconnaîtrait de la CSS (scénario catastrophe, me direz-vous ; oui mais on a déjà vu pire dans certains navigateurs).

Deuxième proposition : utiliser une notation à base de tirets, class="role-contentinfo", et manipuler la chaîne en l’explosant pour générer l’attribut et sa valeur.

Deux situations à différencier

Attention cependant, ARIA propose une approche deux-en-un :

description d’éléments de structure de la page à travers le rôle (les landmarks) ;
description d’éléments interactifs (typiquement les éléments de formulaire).

Selon moi ces deux cas peuvent impliquer une approche différente : le premier cas doit tant qu’à faire fonctionner même sans JavaScript, le deuxième n’a souvent de sens que si JavaScript fonctionne (puisque le changement dynamique d’état ne peut se faire qu’avec JavaScript).

Conclusion

Je serais enclin à faire du code invalide, en particulier dans le cas des landmarks, mais plus partagé sur les propriétés dynamiques (rôles et états des éléments interactifs).

À votre avis ? Faut-il du code invalide, et si oui, quelle méthode choisiriez-vous ?

Sébastien Delorme : Accentuez les lettres majuscules

2009-11-03T21:40:04Z

Faut-il accentuer les lettres majuscules ?

J’ai tendance à régulièrement reprendre ceux qui ne le font pas. Faites-y attention, vous rencontrerez un grand nombre de majuscules non accentuées. Il faut dire que les claviers de PC sont peu adaptés à l’écriture des "É", "È" ou "À". Notre chère Académie française fait d’ailleurs le même constat :

On ne peut que déplorer que l’usage des accents sur les majuscules soit flottant. On observe dans les textes manuscrits une tendance certaine à l’omission des accents. En typographie, parfois, certains suppriment tous les accents sur les capitales sous prétexte de modernisme, en fait pour réduire les frais de composition.

En français, l’accent a pleine valeur orthographique, il convient donc d’utiliser systématiquement les accents, le tréma et la cédille sur les lettres accentuées.

Son absence ralentit la lecture, fait hésiter sur la prononciation, et peut même induire en erreur. Il en va de même pour le tréma et la cédille.

On veille donc, en bonne typographie, à utiliser systématiquement les capitales accentuées, y compris la préposition À, comme le font bien sûr tous les dictionnaires, [...]

Source : Accentuation des majuscules (Académie Française)

Les synthèses vocales sont bien évidemment les premières à être induites en erreur en l’absence des accents ou cédilles sur les lettres majuscules. Ça peut paraître être un détail mais c’est un réel confort pour la lecture.

Pour saisir vos majuscules accentuées, plusieurs possibilités :

En apprenant les codes des lettres et les combinaisons de touches de votre ordinateur (variable entre Mac et PC) : Comment taper une majuscule accentuée ? ;
Même chose en beaucoup plus complet : Aide : Lettres accentuées sur Wikipedia (avec la liste de toutes les lettres accentuées) ;
En utilisant un pilote de clavier enrichi comme kbdfr dk ;
À l’ancienne, en copiant-collant depuis une liste toute prête : À, Ç, È, É, Ê, Ô, Ù (pour ne citer que les plus courants) ;
Ou via toute autre méthode que vous pourrez également trouver via votre moteur de recherche préféré.

BritoWeb : Un site sur le design et le daltonisme

2009-10-27T16:44:00Z

Outre les problèmes liés au contraste, l'emploi de la couleur peut causer des problèmes d'accessibilité pour les utilisateurs daltoniens.

Étant donné que la prise en compte du daltonisme commence dès le stade de l'élaboration des maquettes graphiques (et même de la charte graphique), un site Web a vu le jour, qui est susceptible d'intéresser les graphistes et autres webdesigners : We are Color Blind, qui fourmille d'exemples (bons et mauvais) de modèles de design.

À ajouter à vos signets.

Où placer les cases à cocher et les boutons radios ?

2009-10-15T10:30:15Z

Je traine quelques questions récurrentes (d’ordre technique ou ergonomique) depuis que je fais des formulaires. Et vu que je suis sympa, je partage un peu avec vous.

Habituellement on fait ça :

Civilité

Nom :

Prénom :

Majeur

Sexe

Homme

Femme

Et moi, j’ai tendance à proposer cette solution (qui est généralement refusée) :

Civilité

Nom :

Prénom :

Majeur :

Sexe

Homme :

Femme :

Alors, boutons radios et cases à cocher : à droite ou à gauche ?

Comment concevez-vous vos formulaires de recherche ?

2009-10-12T22:09:58Z

Dans son dernier billet, Raphaël de Robiano, consultant en ergonomie, a effectué un test utilisateur sur un site Web. Il soulève un détail intéressant en ce qui concerne les formulaires de recherche. Je cite :

Ce test a été l’occasion d’identifier un problème sur un des formulaires de recherche du site que j’aimerais partager avec vous.

Le champ de recherche était accompagné sur la droite d’un petit bouton permettant de valider les caractères introduits et de déclencher le processus de recherche. Ce bouton représentait un petit triangle pointant vers la droite.

Or certains participants au test ont pensé qu’en cliquant dans ce champ, ils obtiendraient une liste déroulante reprenant l’ensemble des produits de la compagnie. Et, en effet, il y a une certaine similarité entre le bouton déclenchant la recherche et celui des listes déroulantes classiques (la balise SELECT pour les familiers du HTML).

D’autres participants ont bien identifié cet élément comme un formulaire de recherche, mais se sont fait la remarque qu’un bouton « search », « go » ou « ok » serait plus approprié.

Comme quoi, la présence d’un petit élément graphique, peut parfois avoir un effet significatif dans l’interprétation de l’interface d’un site.

Voulant approfondir et échanger avec vous sur le sujet, j’ai regardé ce qu’il en était des formulaires de recherche sur d’autres sites sélectionnés au hasard : Twitter, Amazon, Facebook , Linkedin, Skype , Orange et Cyberpresse.ca

Le formulaire de recherche de Twitter :

Le formulaire de recherche de Amazon :

Le formulaire de recherche de Facebook :

Le formulaire de recherche de Linkedin :

Le formulaire de recherche de Skype :

Le formulaire de recherche du site de Orange :

Le formulaire de recherche du site Cyberpresse.ca (Google ) :

Je remarque que la mention ” Rechercher ” est celle qui est le plus utilisée. Il arrive aussi qu’on l’accompagne des mots ” OK ” ou ” GO” . À mon avis, je crois que la mention “Rechercher”inscrite directement dans le champ de recherche avec l’ajout icône ( loupe ) à droite est un choix intéressant.

À titre d’information, je partage avec vous un un article dont je me suis rappelée après la lecture du billet de Raphaël de Robiano. L’article en question traitait les observations de Jakob Nielsen. Je cite le passage intéressant sur le sujet :

3- Le moteur doit ressembler à un moteur !

Le moteur de recherche doit être facilement repérable par l’internaute. Mieux vaut donc éviter les libellés “amusants” ou originaux pour le bouton de recherche: “chercher” ou “rechercher” convient mieux que “trouver”, “OK”, “allons-y !” ou autres… éventuellement, “OK” ou “go !” est acceptable, à condition que le mot “recherche” (ou : “rechercher dans monsite.com”) figure avant le champ de saisie, comme suit:

la recherche sur amazon.fr

De plus, il est préférable que le bouton de recherche soit facilement identifiable comme tel: un bouton standard de formulaire, même si son esthétique est moyennement appréciée des designers, présente l’avantage d’être immédiatement reconnu. Si vous choisissez d’utiliser une image, arrangez-vous pour qu’elle ait bien l’air d’un bouton: forme allongée aux extrémités arrondies, et/ou dessin ombré suggérant le relief.

|
a priori, aucun problème d’identification pour ces boutons

Qu’en pensez-vous.

Comment concevez-vous vos formulaires de recherche ? Quelles mentions avez-vous tendance à ajouter ? : ” Rechercher ” , ” OK “, “GO” , une loupe, une flèche, ect. ? Intégrez-vous tout simplement le mot ” Rechercher” dans le champ de recherche ? Vous arrive-t-il de choisir un autre terme que ” Rechercher ” ?

AccessiBlogue : Guide sur les avantages et les inconvénients des formats PDF et HTML pour l'accessibilité d'un document

2009-10-06T16:53:38Z

La Coopérative AccessibilitéWeb a le privilège de participer activement à l'élaboration des standards d'accessibilité du gouvernement du Québec depuis le début des travaux en 2007. Au fil des années, nous avons été appelés à supporter le ministère des Services gouvernementaux (MSG) et le comité interministériel de normalisation de l'accessibilité (CINA) dans la rédaction et la validation des exigences qui composent les trois projets de standards. <br />Dans le cadre de ces ambitieux travaux, la question du choix (...)

BritoWeb : RGAA version 2.2

2009-10-01T12:46:00Z

La version 2.2 du RGAA vient d'être publiée.

Toutefois, il ne s'agit pas encore d'une version définitivement validée, comme en atteste le statut du document :

La version en cours prend en compte les recommandations WCAG 2.0 et a fait l'objet d'un appel à commentaires auprès d'un cercle d'experts. Elle est en cours de validation et sera figée suite à la publication de l'arrêté.

En attendant, vous pouvez consulter la version 2.2, qui comporte cinq documents :

Sébastien Delorme : Projets : transcription automatique de vidéos

2009-09-18T08:00:00Z

Vous avez peut-être entendu parler de l'appel à projets sur les services innovants du Web du Ministère de l'économie, l'un des volets numérique du plan de relance. La liste des projets retenus pour l'obtention d'un soutien et d'un financement du Gouvernement à été publiée le 17 septembre 2009 : Liste des projets retenus "Web Innovant".

Parmi les projets de cette liste, l'un d'entre eux a particulièrement attiré mon attention (le premier) :

ACAV : Plateforme vidéo permettant de retranscrire la partie audio en texte en se basant à la fois sur l’analyse automatique du son et la collaboration des utilisateurs.

Partenaires : DailyMotion, LIRIS, Université Claude Bernard Lyon, Eurecom.

Une transcription automatique de bandes sonores, une aubaine pour le référencement des contenus vidéos (d'où la participation de DailyMotion au projet) mais également pour leur accessibilité ! L'aspect collaboratif de cette plateforme est également intéressant et permettrait probablement d'obtenir des transcriptions de bonnes qualités. Ce genre d'outils est aujourd'hui un réel manque pour la génération de sous-titrages.

Google travaille déjà sur un projet similaire avec YouTube, des tests avaient été réalisés l'année dernière sur des vidéos politiques : In their own words : political videos meet Google speech-to-text technology.

À suivre donc.

AccessiBlogue : SGQRI 008 : mise à jour des trois versions du standard gouvernemental d'accessibilité

2009-09-14T23:43:29Z

Ceux et celles parmi vous qui suivez ce blogue depuis ses débuts et qui vous intéressez tout particulièrement à l'évolution du standard gouvernemental québécois sur l'accessibilité des sites Web pour les personnes handicapées savez que depuis environ deux ans, le ministère des Services gouvernementaux (MSG), sur son site Web, rend publiques les plus récentes versions de trois documents normatifs qui couvrent l'accessibilité des sites Web (SGQRI 008-01), des documents téléchargeables (SGQRI 008-02) et (...)

Formation RGAA fin septembre

2009-08-17T12:36:00Z

Je vous rappelle que la prochaine formation "Améliorer l'accessibilité avec le RGAA" aura lieu à Paris du 28 septembre au 1er octobre 2009. La durée de la formation a été portée à quatre jours, mais vous pouvez choisir de venir pour une journée (parcours découverte) ou pour trois jours (parcours technique). Par ailleurs, jusqu'à la fin de l'année, nous offrons un abonnement mon-opquast premium (d'une valeur de 299 Euros HT) aux stagiaires qui s'inscriront aux parcours complets. Il y a déjà des inscrits pour la prochaine session, et si vous voulez être parmi nous, il est prudent de vous y prendre dès aujourd'hui. Pour ceci, téléchargez le programme (lien ci-dessous), remplissez le coupon d'inscription et renvoyez-le-nous par mail, par courrier ou par fax. Pour tout renseignement, appelez-nous au +33 (0)5 56 401 402.

Informations pratiques :

Formation "Améliorer l'accessibilité avec le RGAA"
Un, trois ou quatre jours de formation (trois parcours au choix)
Salle Mediasite - 42 rue Legendre - 75017 Paris - France
Télécharger le programme et le coupon d'inscription (PDF - 357Ko)

Les couleurs et l'accessibilité

2009-08-10T12:20:35Z

En France, la proportion de daltoniens est d'environ 8% chez les hommes et 0,45% chez les femmes (source Wikipédia). Plus de 10% de la population masculine est daltonienne dans le monde, et affectée par une perception des couleurs déficiente. Il existe différentes formes de cécité des couleurs : rouge-vert, vert-brun, et ainsi de suite... Bien entendu, il est très difficile, voire impossible d'éviter de mettre sur son site toutes les couleurs qui pourraient être mal perçues.

Cependant, il est à la portée de tout le monde de faire en sorte que les pages soient lisibles par tous, quel que soit le handicap visuel. La première méthode et la plus simple à mettre en œuvre est l'emploi d'un contraste élevé entre l'arrière plan et les couleurs utilisées pour le contenu de la page.

Dans cet exemple on voit bien que C et E sont plus facilement lisibles parce que le contraste est assez fort. L'affichage de votre page en niveaux de gris peut montrer si oui ou non il y a suffisamment de contraste. Il existe également plusieurs outils en ligne pour effectuer des tests :

Snook Color Contratst Checker permet d'indiquer si la différence de contraste entre les couleurs est suffisant pour les différents types daltonisme, en précisant la conformité aux critères WCAG 2
ColorSchemeDesigner permet de simuler la vision d'une palette de couleurs par un daltonien grâce à l'outil "vision simulation"

En plus de faire attention aux couleurs employées, je vous rappelle qu'il est important de garder à l'esprit que la couleur ne soit jamais la seule indication de sens. Par exemple :

distinguer les liens du texte normal en les soulignant
ne pas conditionner les actions de l'utilisateur en faisant appel aux couleurs (ex : "cliquez sur le bouton rouge")
toujours prévoir une alternative texte pour les images (attribut alt)
le texte ne doit pas être remplacé par une image (sans alternative) pour permettre à l'utilisateur de l'agrandir ou d'utiliser sa propre feuille de style contrastée