Outils Microsoft facilitant le développement de sites Web accessibles

Outils Microsoft facilitant le développement de sites Web accessibles
Bernard Ourghanlian Directeur Technique & Sécurité Microsoft France

Sommaire Introduction Une première approche de la problématique
Le développement de technologies accessibles au sein de Microsoft Le Web et l’accessibilité Généralités Développer des projets Web prenant en compte l’accessibilité Contexte normatif et législatif Les outils Microsoft Microsoft Content Management Server 2002 Microsoft SharePoint Services 2.0 et SharePoint Portal Server 2003 Les fonctionnalités disponibles en standard avec la plateforme Windows Un aperçu de Windows Vista, la prochaine version majeure du système d’exploitation Nouveau modèle d’accessibilité pour Windows Le concept de « facilité d’usage » Les fonctionnalités d’accessibilité standards Conclusion Ressources

Introduction

L’attachement de Microsoft à l’accessibilité
L’expression du plein potentiel de chacun La mission de Microsoft est de mettre son expertise, sa capacité d’innovation et la passion qui l'anime au service des projets, des ambitions et de la créativité de ses clients, afin de faire de la technologie leur meilleure alliée dans l’expression de leur potentiel Nous soutenons la vision d’une technologie informatique qui puisse se mettre au service de chacun, y compris pour celles et ceux souffrant de handicaps Un engagement permanent sur la durée Depuis plus de 15 ans, nous explorons et faisons évoluer les technologies d’accessibilité Ainsi, dès 1988, nous avons lancé nos premiers travaux dans le domaine de l’accessibilité en collaboration avec le Trace Research and Development Center de l’université de Madison dans le Wisconsin. Ceci nous a permis de développer, à destination des sourds et des malentendants ainsi qu’aux personnes à la dextérité limitée, les premiers éléments complémentaires à Windows 2.0 appelés « Access Utility for Windows 2.0 » et permettant grâce aux fonctionnalités StickyKeys, FilterKeys et MouseKeys (encore présentes dans Windows XP aujourd’hui mais ayant considérablement évolué) de simplifier les opérations de clavier et de souris et de fournir un retour visuel quand l’ordinateur émet des sons (ShowSounds), tout en permettant à des périphériques spécialisés d’interagir avec l’ordinateur à travers un port série (SerialKeys). Depuis, cet effort s’est constamment poursuivi A ce effet, nous avons construit de nombreux partenariats afin d’accélérer l’innovation en matière d’accessibilité

Réaliser le potentiel de chacun
eInclusion/Digital Inclusion Le but du plan d’action de la commission européenne i2010 est de rendre la société de l’information accessible à tous et l’eInclusion est un élément clé de ce processus L’eInclusion est un objectif clé de la stratégie de l’emploi et l’inclusion sociale en Europe L’inclusion numérique a pris son élan dans le monde en se concentrant sur l’accès à la technologie pour tous Le nombre de personnes pouvant tirer parti des technologie d’accessibilité est largement supérieur à ce qui avait été imaginé initialement

Qu’est-ce qu’une technologie d’accessibilité ?
Les technologies d’accessibilité sont des technologies flexibles et ajustables aux besoins de l’individu en termes de vue, de mobilité, d’ouïe, de langage et d’apprentissage Elles permettent l’accès à l’ordinateur pour des personnes handicapées, quelles que soient leurs capacités fonctionnelles Les solutions technologiques d’accessibilité permettent à chacun de réaliser son plein potentiel Produit standard (accessibilité intégrée) Technologies d’assistance

Les engagements de Microsoft
Microsoft prend en compte les besoins des personnes handicapées ou malades dans le domaine de l'informatique pour leur permettre de bénéficier des nouvelles technologies tant dans leur cadre professionnel que pour leur usage personnel. Microsoft a reconnu très tôt que les technologies informatiques constituaient un outil important et puissant pour les personnes souffrant d’un handicap ou d’une diminution de leurs facultés. Depuis bientôt deux décennies, Microsoft a exploré et fait évoluer les fonctionnalités d’accessibilité qui sont intégrés dans ses produits. Microsoft s’est engagé à offrir des innovations continues dans ce domaine (Cf. « Microsoft's Corporate Mission and Accessibility Strategy ») et a constitué à cette attention l’Accessible Technology Group (ATG) dont les 50 personnes dédiées gèrent et coordonnent tous les efforts associés au sein de la société. L’engagement de Microsoft pour l’accessibilité contribue à donner aux gouvernements les moyens de choisir des technologies accessibles ; ce qui améliore notamment les opportunités d’emploi des personnes souffrant d’une invalidité ou d’une incapacité et offre un meilleur accès aux services publiques. Microsoft supporte les initiatives, directives et réglementations des gouvernements pour piloter l’inclusion numérique en mettant à disposition l’information sur l’accessibilité des produits Microsoft, et comment ils répondent à une variété de standards d’accessibilité communément adoptés.

Les engagements de Microsoft
Aux Etats-Unis notamment, la section 508 du « Rehabilitation Act » impose aux agences fédérales de rendre leur technologie informatique et électronique accessible aux personnes handicapées. La Section 508 crée une forte motivation pour les éditeurs de logiciel afin d’intégrer plus et de meilleures fonctionnalités d’accessibilité au sein de leurs produits. Elle complémente et renforce le travail que Microsoft a déjà entrepris pour rendre la technologie universellement accessible. Pour de plus amples informations, vous pouvez vous référer à l’engagement public de Microsoft l’adresse Internet « Microsoft Actively Supports Section 508 ». En Europe, Microsoft supporte l’initiative eInclusion de la Communauté Européenne mentionnée précédemment et participe aux efforts transatlantiques de support de i2010.

Pour élargir la perspective…
Microsoft a commissionné une étude pour : Mieux comprendre le marché des technologies accessibles Obtenir des informations sur la façon dont les gens utilisent les ordinateurs L’étude de Forrester Research, Inc a porté sur personnes aux USA au printemps 2003 Des considérations démographiques complémentaires suggèrent que les résultats de l’enquête auraient été identiques en d’autres points du globe, notamment en Europe En 2010, presque la moitié de la population dans des pays tels que la Belgique, l’Allemagne et la France auront 45 ans et plus En 2050 il y aura presque deux fois plus de « vieux » de plus de 60 ans que de «jeunes » de moins de 20 ans

Les conditions de l’enquête
Questionnaire complet comprenant des questions permettant : D’identifier des personnes se considérant elles-mêmes comme souffrant de difficultés ou de handicaps D’identifier des personnes qui ne se considèrent pas elles-mêmes comme souffrant d’un handicap mais se considérant comme ayant des difficultés à effectuer leurs tâches de tous les jours Bénéfices de cette approche Identification de groupes de personnes souffrant de difficultés physiques ou cognitives ou de handicaps les restreignant dans leurs activités de tous les jours Capture d’informations pour chacun des groupes de personnes

Les questions de l’enquête
Pour chaque type de difficulté ou de handicap (visuel, dextérité, ouïe, parole, cognitif) les questions suivantes ont été posées : Difficultés dans les tâches de tous les jours Questions directes à propos des handicaps afin d’évaluer la proportion de la population qui s’est elle-même identifiée comme souffrant de handicap Questions directes au sujet de l’impact sur l’emploi afin de permettre aux personnes de communiquer leur évaluation sur les contraintes imposées par un handicap

Une nouvelle perspective
Les anciennes définitions avaient créé deux catégories : les handicapés et les autres Cette enquête montre Que la plupart des individus ne s’identifient pas eux-mêmes comme ayant une difficulté ou un handicap Il y a un continuum de difficultés et de handicaps physiques et cognitifs qui comprend les personnes handicapées Les populations vieillissent Les anciens restent au travail plus longtemps que leurs ainés Les difficultés et les handicaps augmentent avec l’âge

Les personnes susceptibles de bénéficier des technologies accessibles
57% des utilisateurs d’ordinateurs (18 – 64 ans) sont susceptibles ou très susceptibles d’en bénéficier 1 utilisateur sur 4 a des difficultés visuelles 1 utilisateur sur 4 a des douleurs aux mains ou aux poignets 1 utilisateur sur 5 a des difficultés auditives Very likely to benefit 17% Likely to benefit 40% Not likely to benefit 43% Base: US year old computer users Enquête commissionnée par Microsoft, Conduite par Forrester Research en 2003

Le développement de technologies accessibles au sein de Microsoft

Concevoir du logiciel accessible
Microsoft Accessibility Guide (MAG) Collection de l’ensemble des normes et standards et des lois liés à l’accessibilité dans le monde Conçu pour communiquer ces normes, standards et loi sous la forme d’action concrète au sein des groupes produits de Microsoft Cas de tests, détails techniques d’implémentation et autres ressources développés autour de points de contrôle afin d’être utilisé par les groupes produits Les Program Managers conçoivent les fonctionnalités des produits en se focalisant sur les normes et standards d’accessibilité et les législations en utilisant les points de contrôle MAG Des études d’utilisabilité sont également conduites afin de vérifier l’utilisabilité et l’accessibilité de la conception du produit

Développer du logiciel Accessible
Les développeurs créent une interface homme – machine (IHM) fournissant un accès programmé à cette IHM L’accès programmé collecte des informations au sujet de l’IHM et lui permet d’être exposée à l’utilisateur Interagit avec les éléments de l’IHM tels que cliquer sur un bouton, parcourir une liste, déplacer une fenêtre, fraper sur des touches, etc. Les testeurs se concentrent sur l’identification des problèmes qui doivent être corrigés avant de livrer le produit Le but est d’identifier et de corriger tous les bogues qui bloqueraient l’accès de l’utilisateur à l’IHM Construction de cas de test à partir des ébauches de cas de tests contenus dans le MAG Test avec des technologies d’assistance dans le Microsoft Accessibility Lab

Outils de développement pour créer du logiciel accessible
Microsoft Office FrontPage 2003 comprend un outil de contrôle de l’accessibilité sur le Web Permet aux développeurs Web d’identifier les problèmes potentiels d’accessibilité par rapport au Web Content Accessibility Guidelines (WCAG) - version 1.0 du World Wide Web Consortium (W3C) Visual Studio 2005/ASP.NET Intègre en standard un outil de contrôle d’accessibilité pour permettre aux développeurs d’identifier les problèmes potentiels d’accessibilité Fournit aux développeurs des informations de programmation « automatiques » lors de l’utilisation de common controls

Documenter l’accessibilité de chacun des produits
Voluntary Product Accessibility Template (VPAT) Documents disponibles publiquement en Documente tous les bogues qui empêchent un utilisateur présentant un déficience ou un handicap d’accéder ou d’activer une fonctionnalité quelconque du produit Document « vivant » mis à jour quand une erreur nouvelle est trouvée ou que le produit est mis à jour Permet aux groupes produits de répondre aux retours des utilisateurs, notamment celles des associations

Microsoft Assistive Technology Vendor Program (MATvp)
Programme librement accessible pour les fournisseurs de technologies d’assistance, les chercheurs, les associations, etc Permet à Microsoft et aux constructeurs de solutions logicielles et matérielles d’assistance (tels que des lecteurs d’écran, des périphériques d’entrées, etc.) de travailler en étroite coopération afin de s’assurer que les fournisseurs de tels périphériques disposent bien de toute l’information nécessaire pour construire des produits compatibles avec Windows et les autres logiciels Microsoft

Quelques informations complémentaires sur MATvp
Vingt sous-catégories de technologies d’assistance regroupées en 5 catégories majeures de handicap Vision Ouïe Parole Mobilité Cognitif Participation internationale Plus de 145 membres dans le monde 20 pays dont la France Deux périodes d’adhésion par an Permet la participation aux beta tests des logiciels et l’accès au support Premier

Le Web et l’accessibilité

L'utilisation du Web fait partie intégrante de notre vie quotidienne et se répand rapidement dans tous les domaines de la société. Le Web constitue, à ce titre, la source d'information la plus globale. Pour autant, les personnes handicapées éprouvent des difficultés à utiliser à ce médium, ainsi que, d’une façon générale, les services (interactifs) proposés en ligne. Comme le souligne Tim Berners-Lee, directeur du W3C et « inventeur » du World Wide Web : « La puissance du Web réside dans son universalité. L’accès par tous quel que soit le handicap en est un aspect essentiel » Le problème ne réside pas dans l’accès à l’informatique (selon certaines études, les personnes handicapées visuelles seraient deux fois plus équipées en ordinateur que la moyenne nationale de la France). Le problème réside réellement dans l’utilisation du Web : les sites Web que ces personnes visitent ne sont pas toujours adaptés aux dispositifs d'assistance qu'elles utilisent ou n'incluent aucune caractéristique d'accessibilité, même élémentaire.

Tim Berners-Lee, directeur du W3C et « inventeur » du World Wide Web, donne cette définition de l’accessibilité numérique : En d’autres termes, l'accessibilité numérique peut se définir simplement comme « la capacité d'une personne – quel qu’elle soit – à accéder à la toile » : un site Web est accessible s'il peut être utilisé indifféremment par une personne présentant ou non un handicap quel qu’il soit. Le contenu, les caractéristiques et les services offerts par un site se doivent d’être accessibles à un public aussi large que possible, indépendamment de l'âge, d'un handicap ou des limites de la technologie ou de l'environnement de l'utilisateur. « Mettre le Web et ses services à la disposition de tous les individus, quel que soit leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales. Mettre les services et les contenus de communication en ligne à la disposition de tous les individus, quel que soit leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales »

A titre d’illustration, il y a dans le monde plus de 750 millions de personnes qui souffrent d'un handicap. Le document « Le handicap en chiffres – version 2004 » du Ministère de la Santé donne un aperçu de la situation en France Si toutes ces personnes n'utilisent pas toutes les services de la toile Web, faute dans certains cas de disposer tout simplement des moyens (financiers, techniques, etc.) d’y accéder, nombre d’entre elles cherchent à en bénéficier et il semble juste et équitable de supprimer autant que possible les divers obstacles qu'elles rencontrent lors de leur navigation sur la toile

L'accessibilité du Web est souvent perçue comme le fait de donner accès aux contenus numériques pour les personnes handicapées Pourtant, rendre un site accessible présente d'autres avantages dépassant largement le simple champ du handicap et va bien au-delà de la compatibilité des aides techniques des personnes handicapées avec les sites Web Ceci est loin de se limiter aux personnes handicapées Lorsque l'information Web est conçue et réalisée pour être accessible aux personnes handicapées Les sites résultants s’en trouvent généralement construits de manière plus logique et mettent l'accent sur le contenu plutôt que sur la fourniture d'information Les frais de maintenance s’en trouvent d’autant réduits. Les sites accessibles deviennent utilisables à partir d'ordinateurs d’entrée de gamme disposant de connexions Internet plus lentes, etc. Ceci permet également d’améliorer la portabilité des sites sur l’ensemble des supports d’affichage tels qu’un téléphone mobile avec accès Internet ou un assistant numérique personnel Constat important quand on comptabilise 810 millions de terminaux mobiles vendus en 2005

Accessibilité ou « utilisabilité » ?
Bien que ces deux notions soient étroitement liées, elles présentent néanmoins quelques différences essentielles. Si certains sites Web sont techniquement accessibles, ils n’en sont pour autant pas toujours simples à utiliser. Un site Web accessible n'est donc pas systématiquement utilisable. Alors que l'accessibilité a pour objet essentiel d'« ouvrir » (les portes d’) un site Web à une population d’utilisateurs la plus globale, l'utilisabilité vise en revanche en termes d’objectifs à améliorer la satisfaction, l'efficacité et l'efficience de la population cible dudit site. L'accessibilité couvre des aspects/considérations techniques, l'utilisabilité concerne l'expérience, celle de l'utilisateur lorsqu'il accède à un site Web donné. L'utilisabilité est assez comparable à une qualité en ce sens où on ne la remarque que lorsqu'elle fait défaut ! L'utilisabilité pourrait donc se définir comme « la facilité avec laquelle les visiteurs peuvent utiliser un site Web ». L'utilisabilité du Web ne se limite pas à s'assurer que tout fonctionne bien sur le site mais également à mesurer à quelle vitesse et avec quelle aisance les visiteurs peuvent utiliser le site.

« Utilisabilité » du Web
L'utilisabilité du Web couvre non seulement des éléments tels que l'intuition ou encore la convivialité pour l'utilisateur mais également le temps de téléchargement, la présentation d'une page, l’infographie, l'animation, la navigation, l'architecture de l'information, la recherche, etc. On ne peut l'apprécier que par l'expérience et la satisfaction de l'utilisateur final : L'utilisateur peut-il aisément trouver l'information qu'il recherche ? Les services offerts sont-ils faciles d'accès et les informations fournies sont-elles simples à comprendre ? Le contenu du site est-il présenté de manière cohérente ? Le site dispose-t-il d’une structure logique et compréhensible et permet-il une navigation aisée et efficace ? Le site fournit-il des explications relatives à la manière dont il est organisé et au fonctionnement de la navigation ? L'utilisateur peut-il travailler en interaction avec le site et fournir un retour d'informations ? Obtient-il une réponse rapide et satisfaisante ? Le site propose-t-il des paramètres de recherche ? Etc.

Quelques préjugés et malentendus classiques...
Quelques préjugés viennent freiner la prise en compte de l’accessibilité. D’aucuns semblent convaincus que : Les personnes handicapées n’ont pas accès à l’informatique alors pourquoi donc se soucier d’Internet pour elles. Ceci est invalidé par les aides techniques et logiciels d’assistance disponibles D’ailleurs, selon certaines études, les personnes handicapées visuelles par exemple seraient deux fois pus équipées en ordinateur que la moyenne nationale en France… Internet est un média fondé sur l’image ou autres éléments multimédias donc impossible à rendre accessible pour les personnes handicapées visuelles par exemple. Offrir un texte alternatif à une image rend l’information véhiculée lisible par une plage braille ou une synthèse vocale. L’accessibilité tue la créativité : les pages Web accessibles sont des pages qui ne contiennent que du texte et qui sont dès lors ennuyeuses ou monotones. Fort heureusement, il n'en est rien : l'accessibilité du Web n'est pas une question de restrictions conduisant à des interfaces pauvres mais d'améliorations. Il s'agit de s'assurer qu'un contenu non textuel soit accessible aux personnes présentant un handicap.

Développer des projets Web prenant en compte l’accessibilité

Développer pour l’accessibilité
L’accessibilité n’est pas une contrainte mais une garantie explicitée au sein d’un processus Qualité. Chaque étape d’un projet est concernée, de la réflexion la plus amont jusqu’au suivi en passant par la réalisation ou l’accompagnement. Ainsi, la prise en compte de l’accessibilité dans la conception impacte tous les niveaux : ergonomique, graphique et technique. L’expérience des équipes projet et les solutions, outils et technologies envisagés doivent permettre la mise en place d’interfaces Web performantes et adaptées aux cibles tout en respectant les recommandations de la WAI liées à l’accessibilité.

Le respect des recommandations liées à l’accessibilité se doit d’être pris en compte dès la phase de conception au niveau de : La création des maquettes graphiques intégrant une majorité de handicaps ; La vérification de principe et l’adaptation de certaines ergonomies « standards » si nécessaire ; La définition du « story-board » par une prise en compte de critères spécifiques telle que la gestion des tableaux de données ; La définition et rédaction de la charte éditoriale par la mise en place de règles systématiques (longueur des contenus, utilisation des acronymes, hiérarchie des contenus, etc.) ; La sélection des outils de gestion de contenu en s’assurant que les futurs contenus produits seront accessibles ; La définition pour cela d’un cadre de testabilité intégrant dans le plan de test l’utilisation d’outils de navigation adaptés comme Lynx, JAWS, etc. en plus des browsers Web cibles. Les tests de validation « accessibilité » doivent être systématiquement intégrés à la démarche Qualité des projets Web ; Etc.

Chaque livrable résultant doit être contrôlé, évalué de façon à s’assurer qu’il respecte les critères d’accessibilité. La phase de réalisation doit garantir le strict respect des standards et des dispositions adoptées dans la phase de conception. Rigueur, cohérence et procédures de tests renforcées sont les maîtres mots de cette démarche. L’adoption d’une démarche méthodologique souple et dynamique comme Microsoft Solutions Framework (MSF) issue des années d'expérience acquises par les équipes de développement de Microsoft et les consultants de Microsoft dans le monde permet d’assurer la maîtrise des processus et des techniques de gestion de projets de ce type. Il est important de noter que tester l’accessibilité d’un site Web à un instant donné n’est pas suffisant car le Web est un environnement très volatile : il est donc vital d’incorporer la démarche de l’accessibilité au sein de l’ensemble des phases d’un projet Web, y compris dans sa maintenance

L’accessibilité numérique garantit un accès égal pour tous mais contribue également à la qualité générale des services, de leur ergonomie et de leur facilité d’utilisation. Elle bénéficie donc à tous. Certains pensent que les caractéristiques d'accessibilité de base sont difficiles et très onéreuses à mettre en œuvre. Ceci faux puisqu'il existe des directives élémentaires qui, moyennant peu d'efforts pour les suivre, peuvent améliorer l'accessibilité et l'utilisabilité des sites Web.

Les technologies d'assistance
Les technologies d'assistance sont des produits utilisés par des personnes handicapées pour pouvoir assumer des tâches qu'elles ne seraient pas en mesure d'accomplir ou qu'elles accompliraient difficilement seules. Rattachées à un ordinateur, les technologies d'assistance sont communément appelées « aides technique ». Certaines aides techniques dépendent du fonctionnement d'autres agents utilisateur tels que le navigateur graphique (par opposition au navigateur texte), le lecteur multimédia, etc. En voici quelques exemples : Clavier adapté ; Clavier virtuel ; Plage Braille ; Agrandisseur d'écran ; Avertisseur sonore ; Lecteur d'écran ou de paragraphe ; Reconnaissance vocale ; Logiciel de lecture optique ; Navigateur texte ; Navigateur vocal ; Etc. Pour de plus amples informations, vous pouvez consulter le document du W3C « Evaluation, Repair, and Transformation Tools for Web Content Accessibility »

Les stratégies adaptatives
Les stratégies adaptatives sont des techniques facilitant la navigation dans les pages Web. Une personne non-voyante ou malvoyante peut utiliser les touches du clavier comme la touche « tabulation » pour passer de liens en liens, d’onglets à onglets dans le cas d’un formulaire etc.qui peuvent être utilisées, avec ou sans l'aide des aides techniques précédentes Ces éléments sont notamment développés dans le document de travail du W3C « How People with Disabilities Use the Web » daté du 10 décembre 2004. On y trouvera une introduction à l'utilisation du Web par des personnes handicapées et de nombreuses explications relativement aux besoins de ces personnes lorsqu'elles utilisent des sites Web et/ou des applications basées sur le Web. Ce document fournit enfin des informations relatives aux instructions et aux travaux techniques de l'initiative pour l'accessibilité du Web du consortium W3C (WAI)

Contexte normatif et législatif

Les recommandations du W3C
L’Initiative d’Accessibilité du Web (Web Accessibility Initiative ou WAI), structure spécialement dédiée aux problématiques d’accessibilité créée en 1996 au sein du W3C, pose les bases d’une standardisation de l’accessibilité numérique avec une série de recommandations.

Les WCAG 1.0 Parmi ses recommandations, le W3C/WAI a notamment publié le 5 mai 1999 la version 1.0 des directives WCAG (« Web Content Accessibility Guidelines 1.0 ») [traduction des directives pour l'accessibilité aux contenus Web] pour l'accessibilité aux contenus Web. Ces directives expliquent comment rendre les contenus Web accessibles aux personnes handicapées. Elles sont écrites à l’attention de tous les créateurs de contenu pour le Web (auteurs de pages et concepteurs de sites) et des développeurs d’outils de création de contenu. Leur objectif principal consiste à promouvoir l'accessibilité (pour les personnes handicapées). Mais, en respectant de telles directives, on peut optimiser le contenu Web pour l’ensemble des utilisateurs, et ce indépendamment du programme utilisateur : browser, navigateur texte, navigateur vocal, Smartphone, etc. et ce quelques soient les contingences imposées par l’environnement d’utilisation (lieu bruyant, sur- éclairé ou sous-éclairé, en gardant les mains libres, etc.) Ceci permet aux utilisateurs de trouver de l’information sur le Web plus rapidement. Ces directives ne cherchent pas à décourager l’utilisation par les créateurs de contenu d’images, de vidéo, etc., mais expliquent au contraire comment rendre ces mêmes contenus multimédias plus accessibles à une large audience. Ces directives définissent des principes stables relatifs à des pages Web accessibles et donnent des orientations sur l'accessibilité des sites Web aux personnes présentant un handicap. Ces directives sont aujourd’hui généralement considérées comme des guides de référence pour la création de pages Web accessibles. Elles ont été reconnues par la plupart des pays, dont la France dès Elles ont été reconnues par l'Europe en 2002.

WCAG 1.0 (suite) Si, d’une façon générale, les recommandations WAI constituent les textes de loi, les WCAG 1.0 en sont les décrets d’application. Les WCAG 1.0 comportent 14 directives qui sont conçues de manière à assurer une compatibilité ascendante avec l'évolution des technologies du Web, tout en permettant aux sites d'offrir un traitement réduit aux navigateurs existants. Ces directives portent sur la conformité (propreté et complétude) du code (X)HTML ainsi que sur des points « de bon sens ». Le code (X)HTML doit être syntaxiquement et grammaticalement correct : balise correctement fermée et imbriquée, attribut entre guillemets, etc. Il doit contenir des informations autorisant une exploitation par toute personne et tout type de logiciels. Ainsi, pour prendre un exemple, les images doivent contenir un texte alternatif, les tableaux de données un résumé et un titre. Une page doit être exploitable même si le navigateur ne comprend pas le JavaScript, le Flash, les éléments multimédia, etc. Ceci signifie que les parties utilisant ces technologies doivent disposer d’un équivalent « HTML pur » au sein de la même page. Dans le même temps, le code doit être le plus léger possible et contenir le moins de code HTML « inutile » afin de ne pas pénaliser les personnes utilisant un navigateur texte ou des aides techniques.

WCAG 1.0 (suite) Les WCAG 1.0 prennent en considération tous les handicaps et reposent sur les standards techniques du Web. Mais suivre ces directives présentent d'autres avantages que de « simplement » permettre l'accès des personnes handicapées au Web. C'est également garantir que les sites Web seront utilisables quelle que soit la configuration du poste : navigateur configuré pour afficher les pages sans images (pour surfer plus rapidement…). Dans ce cas, le texte alternatif apparaît en lieu et place de l'image et permet à l'internaute de disposer de l'information. Cela permet aussi de réduire les frais de maintenance et d’assurer une meilleure portabilité des sites sur l'ensemble des supports d'affichage

WCAG 1.0 (suite) Chaque directive s’accompagne de points de contrôle qui lui sont propres. Ainsi, ce sont 65 points de contrôle qui sont décrits avec des exemples détaillés et des explications quant à la manière de mettre en œuvre les instructions pour l’accessibilité du contenu Web dans le document annexe « Techniques for Web Content Accessibility Guidelines 1.0 » [traductions des techniques pour les règles d'accessibilité du contenu Web 1.0]. Ce dernier renvoie, le cas échéant, selon la problématique à illustrer et le ou les domaines techniques considérés, sur une série de documents annexes : « Core Techniques for Web Content Accessibility Guidelines 1.0 » qui discute des techniques générales d’accessibilité qui s’appliquent à l’ensemble des technologies. « HTML Techniques for Web Content Accessibility Guidelines 1.0 » qui propose des exemples et des stratégies pour la définition d’un contenu accessible avec le langage de description de pages HTML (Hypertext Markup Language) ; « CSS Techniques for Web Content Accessibility Guidelines 1.0 » qui propose des exemples et des stratégies pour l’écriture de feuilles de style en cascade CSS (Cascading Style Sheets) comme composante de la conception d’un contenu accessible ; Compte tenu de l’évolution technologique, ces documents techniques sont régulièrement mis à jour.

WCAG 1.0 (suite) Les WCAG 1.0 s’inscrivent enfin dans une série de recommandations sur l'accessibilité du Web publiées par le W3C/WAI sur son site à la page « WAI Guidelines and Techniques ». Il est à noter que le W3C/WAI propose également une page d’accueil en français regroupant certaines traductions en français de ces documents dont le lien est précisé le cas échéant entre crochets dans la liste suivante. Cette série comprend notamment : « Authoring Tool Accessibility Guidelines (ATAG) 1.0 » [traduction des directives d'accessibilité pour les outils d'édition 1.0] - Ces directives exposent comment les divers outils de création de contenu peuvent être utilisés de manière à créer des pages Web accessibles et indiquent comment rendre accessible un site en tant que tel. « User Agent Accessibility Guidelines (UAAG) 1.0 » [traduction des directives pour l'accessibilité des agents utilisateurs 1.0] - Ces directives expliquent comment améliorer l'accessibilité des navigateurs, des lecteurs multimédias et des technologies d'assistance (Cf. section éponyme § « Les technologies d'assistance ») qui sont en interface avec ceux-ci. « XML Accessibility Guidelines (WAG) Working Draft » - Ces directives expliquent comment s'assurer que les applications basées sur XML favorisent l'accessibilité. De façon à retrouver son chemin dans toutes ces directives, le W3C/WAI propose de guider les premiers pas pour rendre un site Web accessible : « WAI Resources on Introducing Web Accessibility ».

Les priorités et niveaux de conformité
Les WCAG 1.0 distinguent dans la section § 5 « Conformance » trois niveaux de priorité correspondant à trois niveaux de conformité aux directives: Priorité 1 - Les points de contrôle que doivent impérativement respecter les sites. Dans le cas contraire, un ou plusieurs groupes d'utilisateurs seront dans l'impossibilité d'accéder aux contenus et informations proposés par le site. Le respect de ces points de contrôle constitue une condition préalable fondamentale pour rendre les informations Web accessibles à certains groupes d’utilisateurs. Priorité 2 - Les points de contrôle recommandés pour réduire les obstacles dans l'accès aux sites Web. Dans le cas contraire, un ou plusieurs groupes d'utilisateurs seront dans l'impossibilité d'accéder aux contenus et informations proposés par le site. Le respect de ces points de contrôle permet de supprimer certains obstacles significatifs dans l'accès aux contenus Web. Priorité 3 - Les points de contrôle qui améliorent le confort d'utilisation. Dans le cas contraire, un ou plusieurs groupes d'utilisateurs seront dans l'impossibilité d'accéder aux informations contenues dans le document. Le respect de ces points de contrôle permettra d'améliorer l'accès aux documents Web.

Les priorités et niveaux de conformité
Les directives définissent également trois niveaux de conformité afin de simplifier les comparaisons : Niveau de conformité « A » - Un site Web est au niveau A de conformité s'il respecte tous les points de contrôle de priorité 1 Niveau de conformité « Double-A » - Un site Web est au niveau AA s'il respecte tous les points de contrôle de priorité 1 et 2 Niveau de conformité « Triple-A » - Un site Web est au niveau AAA s'il respecte tous les points de contrôle de priorité 1, 2 et 3

Les WCAG 2.0 Le 8 janvier 2003, le W3C/WAI a publié un projet de révision des WCAG sous la forme d’une version 2.0 des WCAG. La dernière révision de proposition en date, le « Web Content Accessibility Guidelines Editor's Draft » du 23 novembre 2005, repose très largement sur les WCAG 1.0 et vise le même objectif : expliquer comment rendre le contenu Web accessible aux personnes présentant un handicap et définir des seuils cibles d'accessibilité. Cette proposition de version 2.0 intègre, par contre, l’ensemble des retours d'information et d’expérience vis-à-vis des WCAG 1.0 et s'intéresse tout particulièrement aux points à contrôler. Elle s'efforce d'appliquer les points à contrôler à un plus large éventail de technologies et d'utiliser un langage qui soit compréhensible pour un public plus hétérogène. Le W3C/WAI travaille ici de manière attentive afin de s'assurer que les organisations et les personnes qui utilisent actuellement les WCAG 1.0 soient ultérieurement en mesure de passer en douceur à la version 2.0 de ces directives. WCAG 1.0 demeure la dernière version approuvée stable et constitue à ce titre la Référence tant que la version 2.0 ne sera pas approuvée à son tour.

Les WCAG 2.0 (suite) Depuis la sortie en mai 1999 des WCAG 1.0, le W3C/WAI a pu collecter nombre de retours d'information et d’expérience vis-à-vis des priorités notamment en ce qui concerne les points à contrôler et l'utilisabilité du jeu de documents proposé, ainsi que des demandes d'éclaircissement à propos de la signification de certains points à contrôler et de ce qu'il y a lieu de faire pour satisfaire aux exigences de contrôle. La proposition de version 2.0, lorsqu'elle deviendra une recommandation W3C (selon toute vraisemblance, dans le courant de l’année 2006), devrait donc, à la lumière des documents disponibles : Etre organisée de manière plus efficace ; Adapter la priorité de certains points à contrôler ; Modifier, supprimer ou ajouter des exigences en raison de l'évolution des technologies Web depuis la publication des WCAG 1.0 ; Inclure l'erratum des WCAG 1.0 ; Refléter l'expérience acquise dans la mise en œuvre des WCAG 1.0 ; Les WCAG 1.0 sont organisé autour de directives auxquels se rattachent des points de contrôle de priorité 1, 2 ou 3. Les points de contrôle constituent la base pour la détermination de la conformité avec les WCAG 1.0. La dernière révision de la proposition 2.0 en date est organisée autour de quatre grands principes de conception d’accessibilité Web. Chaque principe dispose de directives, et chaque directive de critères de succès de niveau 1, 2 et 3. Les critères de succès constituent la base pour la détermination de la conformité avec les WCAG 2.0.

Les WCAG 2.0 (suite) La proposition de version 2.0 des recommandations précédentes pour l'accessibilité du contenu Web proposera plusieurs améliorations par rapport à la version antérieure. Si le principal objectif de la version 2.0 reste identique à celui des WCAG 1.0, à savoir promouvoir l'accessibilité du contenu Web, la version 2.0 comprend des objectifs supplémentaires qui constituent des améliorations et notamment : Veiller à ce que les exigences puissent s'appliquer à toutes les technologies ; Veiller à la clarté des exigences en matière de conformité ; Veiller à ce que les produits soient simples à utiliser ; Rédiger des textes s'adressant à un public plus large ; Identifier clairement les bénéficiaires d'un contenu accessible ; Veiller à ce que la nouvelle version assure une compatibilité descendante avec les WCAG 1.0 pour l'accessibilité du contenu Web

Le label AccessiWeb En France, les travaux de l’association BrailleNet dans l'accessibilité du Web depuis 1997 a conduit à l'élaboration d'un label de Qualité : « AccessiWeb » qui veut permettre, dans l’attente d’une certification nationale ou européenne, de mesurer l’accessibilité des sites Web. Le label AccessiWeb vise à qualifier l'accessibilité d'un site Web dans son concept général (accessible à tout le monde et quelle que soit la technologie de consultation utilisée) conformément à la définition de Tim Berners-Lee et non pour un type de technologie ou pour une population spécifique. Pour cela, le label AccessiWeb se fonde sur le fait que l'application des recommandations internationales du W3C/WAI et en l’occurrence des directives des WCAG 1.0, dont le principe est clair et non contesté, nécessite une interprétation et des adaptations selon le contexte. Pour cela, une méthode d'implémentation et de vérification est nécessaire, définissant de la façon la plus objective et la concrète possible les conditions de leur mise en œuvre.

Le label AccessiWeb (suite)
En ce sens, ce label constitue une méthode d'application des recommandations du W3C/WAI et comprend 2 éléments indissociables : Une liste de 92 critères AccessiWeb (55 critères « Bronze », 23 critères « Argent », 14 critères « Or ») publiée en décembre 2003 et établie sur la base des 14 directives des WCAG 1.0 précédemment abordées ; à l’exception de 3 critères « Or », ces critères sont tous reliés à un point de contrôle ; Une méthode d'évaluation ; Le Guide AccessiWeb propose une fiche pratique par critère AccessiWeb pour aider à le comprendre, à l'évaluer et à l'implémenter.

Il se décline en 3 niveaux : Niveau Bronze – Un site Web a le niveau « Bronze » si les 55 critères AccessiWeb de ce niveau sont respectés. Un tel site Web offre un bon niveau d'accessibilité qui permet, en particulier aux personnes handicapées, de le consulter via des technologies d’assistance et des stratégies adaptatives; Niveau Argent - Un site Web a le niveau « Argent » s’il a le niveau « Bronze » et si les 23 critères AccessiWeb « Argent » sont respectés. Un tel site Web de niveau « Argent » a un très bon niveau d'accessibilité. Niveau Or - Le site Web a le niveau « Or » si les 92 critères d’AccessiWeb sont respectés. Un tel site Web a un excellent niveau d'accessibilité. Le certificat de chaque niveau est obtenu à l’issu d’un processus de labellisation

En tant que méthode d’application des recommandations de W3C/WAI, les niveaux du label AccessiWeb permettent de vérifier ceux définis dans les WCAG 1.0 (A, AA et AAA) : Un site qui obtient le label AccessiWeb de Bronze a nécessairement le niveau A de W3C/WAI ; Un site qui obtient le label AccessiWeb d’Argent a nécessairement le niveau AA de W3C/WAI ; Un site qui obtient le label AccessiWeb d’Or a nécessairement le niveau AAA de W3C/WAI ; Le tableau de correspondance avec les WCAG 1.0 proposé par BrailleNet peut être consulté à cet effet. Il est à noter que la réciproque n’est pas vraie.

Le cadre juridique en France
La loi n° pour « l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées » adoptée le 11 février 2005 avec son article 47 en fait désormais une obligation, au même titre que l'accessibilité physique des bâtiments : « Les services de communication publique en ligne des services de l’état, des collectivités territoriales et des établissements publics qui en dépendent doivent être accessibles aux personnes handicapées. » La France rejoint ainsi les pays européens comme l’Espagne, l’Italie, le Portugal, le Royaume Uni et la Suède, qui ont déjà pris des dispositions légales dans ce sens en conformité avec les directives européennes et les différents plans d’action et initiatives associées. Les institutions européennes se sont en effet engagées à respecter les normes actuelles en matière d'accessibilité et un grand nombre d'autres organisations de l'Union Européenne partagent cet objectif.

Le référentiel accessibilité des services Internet de l’administration française
Le nombre de sites de communications en ligne dépendant de l'état se chiffre en milliers. La DGME (Direction Générale de la Modernisation de l'État), nouvellement créée à partir du regroupement de quatre directions dédiées à la réforme de l'Etat dont l'ADAE (Agence pour le Développement de l’Administration Electronique), estime qu’environ 7000 sites Web publics concernés par cette mesure et devront être ainsi rendus accessibles. En réalité leur nombre est sans doute beaucoup plus important puisque de nombreux organismes publics développement leurs sites Web, par centaines, tels les universités ou les établissements d'enseignement primaire ou secondaire. Un certain nombre de collectivités et institutions ont d’ores et déjà fait l'effort d'intégrer les recommandations de la WAI et la question de l'accessibilité. C’est le cas par exemple du Sénat, du Conseil Général des Vosges, ou bien encore le site L’obligation s'inscrit dans le cadre de la modernisation de l’Etat et du développement de l’ « administration électronique », autrement dit de l'utilisation des nouvelles technologies, pour arriver à un meilleur échange à la fois au sein des administrations et entre l'administration et les citoyens.

Dans ce contexte et en réponse au point 31 de la résolution du parlement européen du 13 juin 2002 « tous les sites publics européens doivent avoir le niveau double A (AA) du W3C/WAI », l’administration française par la voix désormais de la DGME propose aujourd’hui les bases nécessaires permettant de faciliter la mise en œuvre des WCAG 1.0 (au travers du « Référentiel accessibilité des services Internet de l’administration française – Version 2004 » en s’appuyant sur le label AccessiWeb comme méthode d’application des recommandations de W3C/WAI (Cf. section précédente). Il devrait évoluer avec la très probable disponibilité des WCAG 2.0 en 2006 pour en reprendre les critères de succès.

Le « référentiel accessibilité » vise à définir un cadre technique, méthodologique et organisationnel en matière d’accessibilité des sites et des services disponibles sur intranet et Internet de l’administration française et se compose aujourd’hui pour cela de deux parties : Une première partie traite plus particulièrement de critères d’accès : celle-ci adopte et reprend la liste des 92 critères AccessiWeb Comme indiqué dans la présentation du « référentiel accessibilité », « les délais d’adoption du référentiel international (notamment celui du W3C WCAG 2.0) imposent la publication immédiate d’un référentiel national. Les critères du Référentiel sont appelés à évoluer périodiquement afin de converger vers les travaux internationaux et notamment ceux du W3C/WAI (les WCAG 2.0). » A cette partie « traditionnelle », s’ajoute une seconde partie qui aborde des critères d’utilisabilité Ces critères sont notamment issus des travaux de Jakob Nielsen et de Marie Tahir, experts internationaux reconnus dans ce domaine (« useit.com: Jakob Nielsen's Website »).

Microsoft Content Management Server 2002
Les Outils Microsoft Microsoft Content Management Server 2002

Recommandations de mise en œuvre avec Content Management Server 2002
Microsoft Content Management Server 2002 (MCMS) est une solution dynamique de gestion de sites Internet, intranet et extranet extrêmement dynamiques et personnalisés. MCMS offre la possibilité, entre autres choses : De construire des sites Web dynamiques et évolutifs à l’aide des contrôles MCMS (connectés au référentiel MCMS) en tirant partie de la puissance de l’environnement de développement Visual Studio .NET 2005 (et en partie de la technologie ASP.NET 2.0), de Microsoft SQL 2005 et de standards tels que SOAP et XML; De déployer des sites et du contenu Web d'un serveur vers un autre via un mécanisme souple et extensible d’empaquetage des objets de contenu à l'aide de XML ; Aux utilisateurs, avec un besoin de compréhension minimal des considérations techniques liées au développement de sites, de créer, modifier, publier et gérer leur propre contenu à l’aide d’outils simples d'emploi qui permettent notamment de planifier des actualisations de contenu, de gérer le « workflow » et à partir d'une fenêtre de navigateur Internet ou de Microsoft Word ; A de multiples auteurs de contenu du site, disposant des permissions appropriées, de simultanément créer ou de modifier de multiples parties d’un même site Web en dissociant le contenu du format ;

Pour une flexibilité maximale, MCMS stocke le contenu dans des objets XML, HTML et binaires, dans un référentiel Microsoft SQL Server ; ils sont gérés séparément des éléments de conception ou modèles de site Web. Les modèles de site Web (fichiers source ASPX, ASP ou ASCX) permettent de définir l’apparence générale pour un ensemble de pages au sein d’un site Web MCMS et contiennent le code exécutable. Ces modèles et le code afférent sont stockés au niveau du système de fichiers et peuvent être gérés à l'aide du système de gestion de code source comme Microsoft Visual Source Safe. Les pages Web peuvent ainsi être créées et publiées dynamiquement, MCMS intégrant dynamiquement le code dans le site Web à travers les objets modèles. De cette façon, le contenu peut être personnalisé en fonction du profil et du comportement de l'utilisateur, du périphérique de navigation ou encore de la langue par défaut. La gestion séparée des objets permet l'adaptation rapide du contenu en fonction d'une grande variété d'applications employées au sein de l'organisation et par les partenaires externes. Pour de plus amples informations sur MCMS, vous pouvez vous référer au site Web à l’adresse Internet

Microsoft a le plaisir d’annoncer la disponibilité du livre blanc « Guide de conception et de réalisation de sites accessibles avec les solutions Microsoft » à l’occasion de cette conférence Ce livre blanc constitue un guide de référence vous permettant de produire des sites Web Accessibles basés sur Content Management Server 2002 et/ou les technologies SharePoint. Il définit dans quelle mesure ces technologies offrent le meilleur respect possible des critères AccessiWeb au moins de niveau Bronze

Ce livre-blanc reprend les 55 critères d’accès de la priorité « Bronze » du « référentiel accessibilité » de la DGME et évalue MCMS vis-à-vis de la prise en compte et du respect de chacun d’entre eux. Ces critères correspondent aux 55 critères du label AccessiWeb au niveau « Bronze » développés par l'association BrailleNet et publiés le 13 décembre 2003. Les seuls documents officiels et valides des critères AccessiWeb sont ceux mis en ligne sur le site Web d’AccessiWeb et, en particulier, les critères du label AccessiWeb de Bronze. Ce niveau d’évaluation permet de s’aligner sur la version 1.0 du Guide AccessiWeb publiée le 19 octobre 2005 dernier et qui propose une fiche pratique par critère AccessiWeb pour aider à le comprendre, à l'évaluer et à l'implémenter. Cette première version présente en effet à ce jour 55 fiches correspondantes aux 55 critères du niveau Bronze. Les fiches des critères des niveaux « Argent » et « Or » ne seront incluses qu’à partir de la version 2.0 du guide précédent. Une révision du présent livre-blanc sera alors proposée.

Cette analyse vis-à-vis de MCMS se décline systématiquement selon deux axes : Le premier concerne la création de modèles (templates) qui sont constitués à l’aide du concepteur de modèles. Ceci comprend notamment les mécanismes de navigation qui ont besoin d’être développés pour le site. Le second s’intéresse au contenu à proprement parlé constitué par les utilisateurs disposant des permissions auteur et d’édition et créé dans les pages à l’aide de « placeholder ». Chaque critère est évalué sur la base de son respect direct par MCMS sans développement additionnel vis-à-vis des outils auteur et, le cas échéant, sur la capacité d’adaptation offerte pour atteindre le critère.

Comme mentionnée dans l’introduction, cette évaluation prend en considération le document VPAT (Voluntary Product Accessibility Template) de MCMS 2002. La version de MCMS prise en compte est la dernière disponible à la date de parution de ce livre-blanc ; il s’agit en l’occurrence de Content Management Server 2002 avec le Service Pack 2. Le Service Pack 2 requiert l’application préalable du Service Pack 1a qui requiert à son tour l’installation préalable des « Internet Explorer Web Controls for Content Management Server 2002 with Service Pack 1a ». A ce titre, nous conseillons la lecture préalable des articles « Content Management Server 2002 Service Pack 2 installation information » et « Rational Guide to installing MCMS 2002 Service Pack 2 ». Le Service Pack 2 introduit le support possible de la version 2.0 du Framework .NET et de l’environnement de développement Visual Studio Il est à noter que Visual Studio permet de développer des modèles conformes XHTML qui sont automatiquement valides lors de leur construction.

Visual Studio 2005 est configuré par défaut pour valider les pages vis-à-vis du schéma Internet Explorer 6.0. La validation des pages vis-à-vis d’un schéma XHTML nécessite la sélection de l’un des schémas XHTML via l’option « Tools », « Options », « Validation ». Les erreurs de validation comme l’absence d’une balise de fermeture sont indiquées dans la vue « Source » par une ligne ondulée en rouge sous le contenu posant problème ; les avertissements de validation comme l’utilisation d’une balise obsolète sont indiqués par une ligne ondulée en vert. Le déplacement de la souris sous la ligne considérée permet l’affichage d’une « info Bulle » contenant le message associé. Ces messages peuvent être également affiché au sein de la liste des erreurs (option « View », « Other Windows », « Error List »). Dans le même temps, Visual Studio 2005 met à disposition une fonctionnalité de vérification de l’accessibilité via l’option « Check Accessibility » du menu « Tools ». Cette dernière permet la validation d’un site vis-à-vis des points de priorité 1 et 2 des WCAG 1.0 ou des directives de la section 508. Le résultat de la validation est également disponible depuis la liste des erreurs. L’article MSDN « Building ASP.NET 2.0 Web Sites Using Web Standards » décrit ces fonctionnalités en détail.

En synthèse, le produit Content Management Server 2002 est tout à fait à même de produire des sites accessibles De façon à ce que le lecteur puisse aisément vérifier que tel ou tel critère est effectivement bien atteignable, cette évaluation manuelle s’appuie le cas échéant sur la barre d’outils d’Accessibilité du Web développée par l'équipe d'AIS (Accessible Information Solutions) de NILS (National Information and Library Service - service national d'information et de bibliothèque en Australie). Cette barre d’outils offre de nombreuses fonctionnalités permettant d'évaluer depuis Internet Explorer l'accessibilité d'une page Internet via l’identification des composants structurels et sémantiques d’une page Web : La présence ou non d'alternatives textuelles associées à des éléments graphiques ; La visualisation des informations relatives aux liens (intitulé, adresse, contenu de l'attribut TITLE, etc.) ; La visualisation des informations relatives aux cadres ; La détection de gestionnaires d'événements ; La structuration de la page par l'intermédiaire de balise H ; La linéarisation de la page ; Etc. Cette barre d’outils est accompagnée d’une documentation précisant comment utiliser cette dernière pour aider dans l’évaluation de la conformité WCAG 1.0 ; la barre d’outils permet d’évaluer 50 des 65 points de contrôles des directives WCAG 1.0. Elle s’appuie également sur le lecteur d'écran JAWS (Job Access With Speech) permettant de lire les informations affichées à l'écran à l'aide d'une synthèse vocale et/ou d'un terminal braille.

Considérations pour la conception de modèles et de contenus Web accessibles au niveau « Bronze »
On s’inspire ici des « 10 Quick Tips to Make Accessible Web Sites » [traduction des 10 conseils pour faire des sites Web accessibles] du W3C/WAI qui synthétisent les concepts clé à avoir à l’esprit pour la conception de sites Web accessible. Il s’agit d’extrait des directives WCAG 1.0 (« Web Content Accessibility Guidelines 1.0 ») [traduction des directives pour l'accessibilité aux contenus Web]

Couleurs – Est-ce que l'information donnée/rendue par le biais de la couleur est également lisible lorsque les couleurs sont désactivées ? Les différences de contrastes entre les couleurs sont-elles suffisamment élevées ? Multimédia – Est-il possible de récupérer les informations fournies dans les supports multimédias d’une autre manière ? Le contenu multimédia est-il synchronisé avec son alternative ? Tableaux - Dans un tableau de mise en forme, le contenu est-il correctement ordonné ? Liens (hypertextes) - Chaque intitulé de lien identique amène t-il vers la même destination ? Scripts(, contrôles ActiveX, etc.) - Si un script nécessite une alternative pour être accessible, l'information donnée par cette alternative est-elle équivalente à l'information fournie par le script ? La possibilité de naviguer sur le site à l'aide du clavier est-elle possible Eléments obligatoires - Le contenu de la balise TITLE est-il différent d'une page à l'autre ? Structuration de l‘information (Organisation) – Est-ce que la structuration de l'information est cohérente par rapport au contexte général du site ? La page web est-elle structurée de manière cohérente ? Présentation de l’information - L’ordre d’apparition des informations doit être le même avec et sans feuille de style Aide à la navigation – Le menu principal de navigation interne est-il toujours présent à la même place dans les pages ? L’ouverture d’une nouvelle fenêtre est-elle signalée à l’utilisateur ? L’utilisation de pop-up JavaScript n’est pas recommandée

Aptitude à vérification de l’accessibilité du contenu - De façon à contrôler et évaluer chaque livrable de façon à s’assurer qu’il respecte la « cible accessibilité » du projet, il convient de définir le cadre de testabilité intégrant selon le périmètre du projet le plan de test, de sélectionner les outils, de définir les scripts de test, etc. La page « Selecting Web Accessibility Evaluation Tools » sur le site Web W3C/WAI décrit ce que les outils permettent ou non ainsi que les diverses considérations relatives à la sélection d’outils : Certains outils permettent de tester tout ou partie de l'accessibilité du contenu d'un site Web selon les niveau de conformité aux WCAG 1.0 selon les points de contrôle de priorité 1, 2 et 3 souhaités, la section § de la section 508 « Voluntary Product Accessibility Template » (VPAT), les contrastes de couleurs utilisés dans le site, etc.. D’autres outils sont à même de réparer les pages existantes et le code afférent afin de les rendre accessibles ; ils nécessitent cependant une intervention humaine. Enfin, des outils de filtrage et de transformation peuvent simuler certains handicaps ou des méthodes de navigation différentes. Une liste de plus de 30 outils pouvant servir à l’évaluation, à la reconfiguration, à la réparation, au filtrage ou encore à la transformation est proposée à la page « Evaluation, Repair, and Transformation Tools for Web Content Accessibility » sur le site Web W3C/WAI. Le site AccessiWeb propose également de son côté une page « Outils et technologies ».

Considérations pour la réalisation de modèles et de contenus Web accessibles au niveau « Bronze »
Comme abordé auparavant, la phase de réalisation doit assurer le strict respect des standards et dispositions adoptées dans la phase de conception Rigueur, cohérence et procédures de tests renforcées sont les maîtres mots Comme précédemment, cette section s’inspire des « 10 Quick Tips to Make Accessible Web Sites » [traduction des 10 conseils pour faire des sites Web accessibles] du W3C/WAI qui synthétisent les concepts clé à avoir à l’esprit pour la conception de sites Web accessible. Il s’agit d’extrait des directives WCAG 1.0 (« Web Content Accessibility Guidelines 1.0 ») [traduction des directives pour l'accessibilité aux contenus Web]. Cette liste est croisée avec les critères du label AccessiWeb au niveau « Bronze »

Eléments graphiques – Utiliser systématiquement l'attribut ALT en (X)HTML pour décrire la fonction de chaque graphique (IMG, SHAPE, MAP) et ainsi en fournir une alternative textuelle (critère 1.1). Images et animations - Il convient d’observer les règles suivantes : Cette alternative doit être «» (valeur vide) pour les images de décoration ; Cette alternative doit être appropriée en fonction du contexte ; Cette alternative doit faire moins de 60 caractères ; Pour les images contenant du texte, l’alternative doit contenir ce texte ; Pour les images servant de lien, l’alternative doit donner la fonction du lien ; Utiliser l’attribut LONGDESC pour une description détaillée (critère 1.10) ; Cette description détaillée doit être pertinente ; Images cliquables - Utiliser l'élément MAP et décrire les zones actives de façon pertinente ; Figures et diagrammes - Les décrire dans la page ou avec l'attribut LONGDESC pour une description détaillée ;

Cadres - Utiliser NOFRAMES et des intitulés utiles. Multimédia - Fournir légendes et transcriptions pour l'audio, et des descriptions pour les vidéos. Tableaux - Faciliter la lecture ligne par ligne et résumer. Il convient d’observer les règles suivantes : Mettre un attribut SUMMARY pertinent (information sur la fonction du tableau) ; Mettre un attribut CAPTION au tableau de données ; Mettre des en-têtes dans les tableaux de données : utiliser la balise TH pour chaque colonne ; Utiliser l’attribut HEADER pour chaque cellule d’un tableau de données ; Liens (hypertextes) - Utiliser des énoncés pertinents hors contexte. Il convient d’observer les règles suivantes : L’intitulé du lien doit faire moins de 80 caractères et doit être explicité (éviter « cliquer ici ») ; Utiliser l’attribut TITLE avec une longueur inférieure à 80 caractères pour fournir des informations supplémentaires ;

Scripts (, contrôles ActiveX, etc.) - Fournir une alternative quand le contenu actif est inaccessible ou non traité. Il convient d’observer les règles suivantes : Si un script nécessite une alternative pour être accessible, l'information donnée par cette alternative est-elle équivalente à l'information fournie par le script ? Mettre alors les contrôles de validation des données côté client et côté serveur ; D’une façon générale, éviter les scripts côtés client. Si leur utilisation est inévitable, il est nécessaire de proposer une solution alternative. Veiller à ce que l'information soit présente, accessible même sans les scripts ; Eléments obligatoires - Les éléments suivants selon le contexte doivent être observés : La balise DOCTYPE en début de chaque page L’attribut LANG de la balise HTML doit préciser la langue La balise TITLE dans l’en-tête doit être présente et explicite sur toutes les pages Préciser les changements de langue à l’aide de l’attribut LANG

Structuration de l‘information (Organisation) - Utiliser des en-têtes de sections et une structure cohérente. Le contenu doit être séparé de la présentation : aucune balise HTML de mise en forme ne doit être utilisée (Exemple : BGCOLOR, FONT, B, U, ALIGN, VALIGN, etc.). L’ensemble des éléments de présentation doit être défini via CSS autant que faire se peut La page doit être lisible sans feuille de style CSS. Présentation de l’information - Il convient d’observer les règles suivantes pour les formulaires : La balise LABEL utilisée et associée aux attributs IF et FOR Le bouton de validation (ou l’image utilisée) doit disposer d’un texte alternatif explicite S’assurer que l’ensemble des champs obligatoires est clairement identifié et informer l’utilisateur sur toutes les données à envoyer au serveur (même avec les scripts désactivés)

Vérification de l’accessibilité du contenu - Valider
Considérations pour la réalisation de modèles et de contenus Web accessibles au niveau « Bronze » Aide à la navigation - Les raccourcis clavier définis sur le site doivent être applicables dans chaque page Contenus accessibles - Pas de rafraîchissements automatiques de la page Vérification de l’accessibilité du contenu - Valider

Evaluation et validation d’un site Web MCMS 2002
La validation des pages et des contenus d’un site est à intégrer très tôt dans le processus projet dès la phase de conception. Une telle évaluation et validation peut et doit en effet avoir lieu dès la mise en œuvre des fonctions d’accessibilité de base. Cette dernière peut également servir à déceler des erreurs d’accessibilité éventuelles sur des pages Web existantes.

Les méthodes d’évaluation et l’outillage associé sont à définir au niveau du cadre de testabilité dans la phase de conception du projet. Ces dernières doivent offrir non seulement la meilleure couverture possible des critères AccessiWeb mais également le meilleur niveau d’automatisation. Comme souligné par le « référentiel accessibilité », certains critères ne sont pas automatisables et doivent systématiquement être vérifiées par un expert. Les outils d’évaluation permettent l’évaluation des points de contrôle de priorité 1, 2 et 3 des WCAG 1.0 et pas, à ce jour, celles des critères AccessiWeb au niveau « Bronze ». Il est cependant possible d’établir des correspondances en termes de points de contrôle de priorité 1, 2 et 3 des WCAG 1.0 avec celles des critères AccessiWeb ay niveau « Bronze ».

La définition de l’outillage pourra s’appuyer sur les éléments d’information de la page « Selecting Web Accessibility Evaluation Tools » sur le site Web W3C/WAI ainsi que : La liste de plus de 30 outils pouvant servir à l’évaluation, à la reconfiguration, à la réparation, au filtrage ou encore à la transformation proposée à la page « Evaluation, Repair, and Transformation Tools for Web Content Accessibility » sur le site Web W3C/WAI comme le WAI HTML Table Linearizer Entry Form ; Celle proposée par le site AccessiWeb à la page « Outils et technologies » ; En première approche, la méthode d’évaluation proposée par le site AccessiWeb peut être considérée.

Evaluation préliminaire en ligne proposée par le site AccessiWeb
Le site AccessiWeb propose une évaluation préliminaire en ligne du niveau d'accessibilité des pages d’un site Web selon un processus d'évaluation simplifié en 3 étapes. Ce processus permet de se faire une première idée du niveau d'accessibilité des pages Web mais suppose que les pages à évaluer puissent être accédées depuis Internet ; ce qui n’est pas toujours le cas. Par ailleurs, les résultats de l'évaluation par ce processus ne constituent aucun engagement vis-à-vis de l'obtention du label de Qualité : « AccessiWeb ». Il s’agit simplement ici d’un préalable possible à la certification proposé

Evaluation préliminaire en ligne proposée par le site AccessiWeb
Le processus simplifié proposé se décline comme suit : Etape 1 (HTML) : le site Web est-il HTML valide ? Cette première étape s’appuie sur l’outil en ligne Markup Validation Service du W3C pour valider le contenu HTML et XHTML. Etape 2 (WAI) : le site Web respecte-t-il les recommandations WAI ? Cette seconde étape permet d’évaluer le contenu de la page vis-à-vis des points de contrôles de priorité 1, 2 et 3 des directives W3C/WAI WCAG 1.0. Même si les résultats de cette évaluation automatique ne suffisent pas à évaluer le niveau d'accessibilité d'un site Web selon les critères AccessiWeb, ils contribuent à se faire une première idée. Cette étape s’appuie sur la plateforme d'analyse en ligne WebXACT de la société Watchfire. (Il s’agit d’une version en ligne de l’outil téléchargeable Bobby de cette même société.) Ce dernier permet une analyse semi-automatique des problèmes d’accessibilité au niveau d’une page Web ou d’un groupe de pages Web et est à même d’identifier de multiples problèmes sur un site et de lister les points qu’il n’est pas à même d’évaluer automatiquement et qui requièrent une revue manuelle par un expert. Etape 3 (utilisateur) : le site Web est-il consultable par un non-voyant ? Cette troisième et dernière étape permet de simuler un mode de lecture « linéaire » comme cela est le cas lors de la consultation via des aides techniques matérielles (plage braille) et logicielles (synthèse vocale) et de vérifier ainsi la structure de l'information de la page évaluée : le moteur de recherche est-il bien codé en haut de page ou est-il seulement visuellement en haut de page ? Cette étape s’appuie sur l’outil en ligne Lynx Viewer.

Au-delà de cette évaluation préliminaire
Comme l’illustre l’évaluation des critères AccessiWeb au niveau « Bronze », une approche systématique d’évaluation en termes d’accessibilité suppose de prendre en considération d’autres points. Il s’agit notamment de : Vérifier si toutes les images sont commentées avec un équivalent textuel – comme nous l’avons vu précédemment, les images significatives doivent comporter un équivalent textuel. Ainsi, même sans image, le contenu de la page reste cohérent. Une telle vérification nécessite de désactiver l'affichage des images dans le navigateur. Pour Internet Explorer, il convient pour cela de décocher « Afficher les images » dans le groupe « Multimédia » de l’onglet « Avancé » de la boîte de dialogue « Options Internet ». Cette dernière est accessible depuis l’option « Options Internet » du menu « Outils ». Sur la base de cette configuration, il convient de vérifier que le site reste navigable. Vérifier que les différences de contrastes entre les couleurs sont suffisamment élevées – l’outil d'analyse des contrastes de couleurs proposé en téléchargement gratuit par la société Vision Australia permet de vérifier les combinaisons de couleurs de premier plan et d'arrière-plan afin de déterminer si elles donnent une bonne visibilité de couleurs. Cette identification de la bonne « visibilité des couleurs » se base sur les algorithmes proposés par le W3C.

Au-delà de cette évaluation préliminaire (suite)
Vérifier si tous les liens sont valides - L’outil en ligne Link Checker du W3C permet, par exemple, de vérifier la validité des liens présents sur la page d'accueil du site sur plusieurs niveaux. Vérifier que les scripts ne constituent pas un frein à la navigation – Les scripts (JavaScript, VBScript, etc.), les contrôles ActiveX, etc. ont permis d'apporter une forte interactivité aux pages. Néanmoins, ces éléments sont parfois invisibles pour l'utilisateur (absence de module de visualisation, navigateur trop ancien, etc.). Il s’avère donc nécessaire de vérifier que la présence de tels éléments dans une page ne perturbe pas la navigation d'un utilisateur qui ne peut (ou ne souhaite) pas les visualiser. Un outil en ligne comme Snoop de la fondation Bartiméus Accessibility permet de désactiver les scripts, les feuilles de style, les images, les cadres, etc. et de visualiser sur cette base la page. Vérifier l'accessibilité par clavier – les pages du site doivent être correctement accessibles par clavier. Il convient pour cela de naviguer sans la souris en utilisant exclusivement le clavier et ses raccourcis principaux, en l’occurrence TAB, SHIFT+TAB. Il est alors possible de vérifier que l'ordre de tabulation est correctement respecté et que l’ensemble des liens est pris en compte. Etc.

Canevas d’un plan de testabilité
Compte tenu de tous ses éléments, nous conseillons d’intégrer dans le plan de testabilité en termes d’accessibilité les points suivants : Valider la syntaxe (par exemple, (X)HTML, XML, etc.) avec un outil comme le Markup Validation Service du W3C ou la fonctionnalité de vérification intégrée à l’environnement Visual Studio 2005 ; Valider les feuilles de style (comme les CSS) avec un outil comme le CSS Validation Service du W3C ; Valider les contrastes avec un outil d'analyse des contrastes de couleurs ; Valider (automatiquement) les pages et la navigation à l’aide d’un outil de validation (automatisée) des normes d’accessibilité et d’un outil de validation de navigation. Il convient de noter que les outils logiciels ne peuvent prétendre prendre en considération des critères d’accessibilité comme la signification des textes des liens, l’applicabilité d’un équivalent de texte, etc. comme définis par le label d’AccessiWeb au niveau « Bronze ». Ces outils s’en tiennent à l’évaluation des points de contrôle de priorité 1, 2 et 3 des WCAG 1.0 ou de la section § de la section 508 « Voluntary Product Accessibility Template » (VPAT). C’est, par exemple, le cas du vérificateur d’accessibilité de l’environnement de développement Visual Studio 2005 qui permet la validation d’un site vis-à-vis des points de priorité 1 et 2 des WCAG 1.0 ou des directives de la section 508. Il en est de même pour Office Front Page 2003 qui propose une boîte de dialogue « Accessibility ». Le même niveau de validation est offert.

Canevas d’un plan de testabilité (suite)
Nous conseillons l’utilisation conjointe de deux outils de validation avec une couverture fonctionnelle légèrement différente de façon à croiser systématiquement les résultats d’analyse. Une telle démarche peut s’appuyer notamment sur les fonctions de vérification des environnements de développement ou d’édition Microsoft ainsi que, par exemple, sur : La plateforme d'analyse en ligne WebXACT de la société Watchfire (ou son équivalent téléchargeable Bobby) précédemment abordé L’outil A-Prompt en téléchargement gratuit qui permet d’identifier les problèmes potentiels d’accessibilité et propose le cas échéant une édition guidée pour corriger ces problèmes En termes de validation de liens, un outil comme le Link Checker en ligne du W3C ou le Link Validation Utility de la société HiSoftware peut être utilisé.

Utiliser de multiples navigateurs graphiques, comme Internet Explorer et Firefox, dans leurs versions courantes et précédentes pour l’évaluation et la validation de pages. Il convient d’afficher les pages : En désactivant les éléments graphiques et de s’assurer que l’information est présentée selon une séquence appropriée relativement à la présentation graphique du site ; En désactivant les éléments multimédia comme le son et de s’assurer que le contenu audio est toujours disponible via des équivalents textes ; En désactivant l’utilisation des feuilles de style et de s’assurer que l’information est présentée selon une séquence appropriée relativement à la présentation graphique du site ; En modifiant la taille des polices (plus petite et plus grande) et d’observer si la page est toujours lisible ; En modifiant la résolution de l’écran à 640 x 480 et d’observer si ceci force ou non la page à un défilement (scrolling) horizontal ; De passer l’affichage en noir et blanc (ou d’imprimer la page en noir et blanc) et d’observer si le contraste des couleurs est adapté ; En utilisant les tabulations et les raccourcis clavier vis-à-vis des différents liens et contrôles des formulaires présents dans la page et de vérifier que l’ensemble des liens et contrôles est ainsi accessible et que les liens indiquent clairement leur destination ; En désactivant l’utilisation des scripts, des contrôles ActiveX, etc. et de s’assurer que des équivalents sont fournis. L’outil Snoop mentionné précédemment pourra être utilisé en complément ; Note : En fonction du handicap de la personne réalisant cette série de tests, il peut s’avérer nécessaire pour certains des tests précédents que cette dernière se fasse assister d’une personne ne présentant pas le même handicap.

Utiliser un navigateur texte seul comme Lynx Viewer et examiner les réponses aux questions suivantes : Est-ce qu’une information équivalente à celle offerte dans la page en mode graphique est disponible au travers du navigateur texte ? Est-ce que l’information présentée dans un ordre logique similaire à celle qui est consultée en mode graphique ? Note : une personne expérimentée peut substituer au navigateur texte un navigateur « self-voicing » ou un lecteur d’écran. Un non voyant devra avoir recours à un voyant pour comparer l’information visuellement disponible. Pour un voyant, il devra écouter les yeux fermés et ensuite ouvrir les yeux pour confirmer que l’information est équivalente. Utiliser un correcteur orthographique et grammatical - Une personne lisant une page à l’aide d’un synthétiseur vocal peut être dans l’impossibilité de déchiffrer la meilleure version fournie par le synthétiseur d’un mot comportant une erreur d’orthographe. L’élimination des problèmes orthographiques et/ou grammaticaux améliore la compréhension ; Vérifier la clarté et la simplicité des contenus avec l’aide d’un relecteur (humain) ; Intégrer la revue des contenus par des personnes handicapées.

De façon à améliorer dans le futur l’accessibilité de facto des pages, nous conseillons de consolider les résultats, de synthétiser les problèmes rencontrés dans les tests, de même que les bonnes pratiques acquises qui doivent être perpétuées et étendues. Il convient d’indiquer dans le même temps la méthode qui a permis l’identification du problème, etc. Ceci doit permettre de constituer une base de connaissance Accessibilité.

Instrumentation spécifique à MCMS 2002
Au-delà des outils mentionnés précédemment, nous souhaitons nous intéresser ici à des solutions plus spécifiquement intégrées avec MCMS 2002 et qui sont notamment décrites à la page « Content Management Server: Tool and Technology Partners » sur le site Web MCMS

HiSoftware Access La société HiSoftware propose une suite d’outils intégrée à MCMS 2002 et à l’environnement de développement Visual Studio. AccVerify DS2 offre une vérification programmatique des contenus et permet de répertorier l’ensemble des erreurs/non-conformités avec les standards, avec en complément, une « checklist » des critères qui ne peuvent être vérifiés de façon programmatique. L’AccVerify Integration Pack for Microsoft Content Management Server autorise un accès intégré pour la vérification de l’accessibilité pour les canaux MCMS. Les bénéfices apportés par l’utilisation conjointe de MCMS 2002, d’AccVerify avec le pack d’intégration comprennent sans s’y limiter : La gestion efficace et cohérente de l’accessibilité du contenu tout au long des cycles de vie de développement et de déploiement du contenu ; La réduction des cycles de publication Web en liant les processus de collaboration, de publication et d’audit d’accessibilité ; L’intégration au sein du système de gestion de contenu de l’organisation ; La prise en compte de l’ensemble des points de contrôles de priorité 1, 2 et 3 des WCAG 1.0 et des directives de la Section 508 ; La capacité à réaliser dans son ensemble le processus de vérification de l’accessibilité ; La personnalisation des rapports avec la prise en charge d’une variété de format de rapport comprenant EARL (Evaluation And Report Language) ; Etc.

HiSoftware Access En complément, AccRepair DS2 amène une vérification et une correction de la politique d’accessibilité et des standards requis pour les sites Web. Il supporte non seulement l’ensemble des points de contrôles de priorité 1, 2 et 3 des WCAG 1.0 et des directives de la Section 508 mais également le test d’ « utilisabilité » au travers de l’Usability Test Manager. AccMonitor Compliance Server 2005 est conçu pour la gestion de l’accessibilité et de la qualité des sites Web. L’AccMonitor Integration Pack II for Microsoft Content Management Server permet notamment de vérifier que le contenu est accessible en ce sens qu’il respecte les points de contrôles de priorité 1, 2 et 3 des WCAG 1.0 et des directives de la Section 508. La génération de rapports d’accessibilité peut être réalisée via HTML, délivrée via des modèles personnalisés ou XML, avec l’utilisation d’EARL, etc. AccMonitor peut être programmé pour superviser automatiquement les canaux MCMS et les soumissions de contenus à des intervalles définis. Ceci comprend de façon non limitative les modèles, les soumissions en attente d’approbation, les soumissions approuvées mais supervisées. Cette suite est intégrée au sein de l’offre « Solution for Online Accessibility » développée conjointement par HiSoftware et Microsoft.

Watchfire Compliance Connector
Watchfire Compliance Connector permet la supervision de la conformité avec les standards de l’accessibilité au sein des workflows CMS. Les créateurs de contenu peuvent ainsi utiliser Watchfire Compliance Connector pour soumettre leur contenu au moteur d’analyse Watchfire, soit à la demande soit de façon automatique, dans le cadre du workflow standard. Le contenu en échec vis-à-vis d’une ou plusieurs règles de conformité est automatiquement retourné à son créateur pour correction.

SharePoint Services 2.0 et SharePoint Portal Server 2003
Les Outils Microsoft SharePoint Services 2.0 et SharePoint Portal Server 2003

Recommandations de mise en œuvre avec les technologies SharePoint
Les produits et les technologies SharePoint sont destinés à faciliter le travail d’équipe connectée à l’échelle de l'entreprise. Grâce aux fonctionnalités combinées de Windows SharePoint Services 2.0 et de SharePoint Portal Server 2003, les utilisateurs peuvent créer, gérer et construire facilement leurs propres sites SharePoint et les rendre accessibles à tous dans l’entreprise. SharePoint Portal Server 2003 est un serveur de portail modulable permettant de connecter des personnes ou des équipes et de partager les savoirs en : Intégrant les informations de plusieurs systèmes de façon sécurisée grâce à l'authentification unique et à des possibilités d'intégration d'applications d'entreprise ; Proposant des outils flexibles pour le déploiement et la gestion ; Facilitant le travail d’équipe grâce à des possibilités d'agrégation, d'organisation et de recherche pour les personnes, les équipes et les informations ; Permettant aux utilisateurs du portail de trouver rapidement les informations pertinentes grâce au ciblage et à la personnalisation du contenu et de la mise en page du portail ;

Comme précédemment, dans le livre blanc, chaque critère est évalué sur la base de son respect direct par Windows SharePoint Services 2.0 et, par voie de conséquence, SharePoint Portal Server 2003 et, le cas échéant, sur la capacité d’adaptation pour atteindre le critère. Comme mentionnée dans l’introduction, cette évaluation prend en considération les documents VPAT de Windows SharePoint Services 2003 et VPAT de SharePoint Portal Server 2003. La version de Windows SharePoint Services 2.0, respectivement SharePoint Portal Server 2003, prise en compte est la dernière disponible à la date de parution de ce livre-blanc ; il s’agit en l’occurrence de Windows SharePoint Services 2.0 avec Service Pack 2 respectivement SharePoint Portal Server 2003 Service Pack 2. Ces Service Packs 2 amènent le support de SQL Server 2005. De plus, Windows SharePoint Services avec le Service Pack 2 est à même de s’exécuter sur la CLR de la version 2.0 du Framework .NET. De ce fait, ce dernier peut s’exécuter avec la technologie ASP.NET 2.0. Ceci dit, la conception même Windows SharePoint Services n’a pas évoluée pour utiliser les constructions ASP.NET. Le Service Pack 2 ne modifie pas le comportement du rendu de Windows SharePoint Services. En d’autres termes, Windows SharePoint Services ne dispose pas de la capacité d’utiliser les Master Pages et le Framework Web Part 2.0. Cependant, ces nouvelles bibliothèques de classes sont disponibles pour des Web Parts, des pages, des gestionnaires d’évènement, etc. personnalisés.

Des Web Parts ASP.NET 2.0 sont vus par SharePoint Services avec le SP2 comme des contrôles Web standard et non pas comme des Web Parts. Une voie alternative comme explorée sur le site consiste à encapsuler un Web Part ASP.NET 2.0 dans un Web Part Windows SharePoint Services conçu pour cela. A contrario, SharePoint Portal Server 2003 ne supporte pas la version 2.0 du Framework .NET, même avec le Service Pack 2.0 d’installé qui requiert le Service Pack 2 de Windows SharePoint Services 2.0. Une configuration SharePoint Portal Server 2003 Service Pack 2 avec Windows SharePoint Services 2.0 avec le Service Pack 2 s’appuie sur la version 1.1 du Framework .NET. Ceci n’empêche pas qu’un site SharePoint fonctionnant sous ASP.NET 1.1 invoque des pages exposées par un site ASP.NET 2.0. De plus amples détails sont fournis dans l’article « Service Pack 2 for Windows SharePoint Services and SharePoint Portal Server 2003 ».

Les prochaines versions de Windows SharePoint Services et de SharePoint Portal Server seront basées sur, et feront donc une utilisation intensive de, ASP.NET 2.0 et de ces nouvelles fonctionnalités notamment orientées sur l’accessibilité numérique comme décrit dans l’article MSDN « Building ASP.NET 2.0 Web Sites Using Web Standards ».

Pour plus d’information sur la mise en œuvre de sites Web accessibles avec les technologies SharePoint, nous recommandons au lecteur de consulter le livre blanc « Guide de conception et de réalisation de sites accessibles avec les solutions Microsoft » distribué à l’occasion de cette conférence

Recommandations de mise en œuvre
Microsoft a le plaisir d’annoncer la disponibilité du livre blanc « Guide de conception et de réalisation de sites accessibles avec les solutions Microsoft » à l’occasion de cette conférence Ce livre blanc constitue un guide de référence vous permettant de produire des sites Web Accessibles basés sur Content Management Server 2002 et/ou les technologies SharePoint. Il définit dans quelle mesure ces technologies offrent le meilleur respect possible des critères AccessiWeb au moins de niveau Bronze

Ce livre-blanc reprend les 55 critères d’accès de la priorité « Bronze » du « référentiel accessibilité » de la DGME et évalue MCMS vis-à-vis de la prise en compte et du respect de chacun d’entre eux. Ces critères correspondent aux 55 critères du label AccessiWeb au niveau « Bronze » développés par l'association BrailleNet et publiés le 13 décembre 2003. Les seuls documents officiels et valides des critères AccessiWeb sont ceux mis en ligne sur le site Web d’AccessiWeb et, en particulier, les critères du label AccessiWeb de Bronze. Ce niveau d’évaluation permet de s’aligner sur la version 1.0 du Guide AccessiWeb publiée le 19 octobre 2005 dernier et qui propose une fiche pratique par critère AccessiWeb pour aider à le comprendre, à l'évaluer et à l'implémenter. Cette première version présente en effet à ce jour 55 fiches correspondantes aux 55 critères du niveau Bronze. Les fiches des critères des niveaux « Argent » et « Or » ne seront incluses qu’à partir de la version 2.0 du guide précédent. Une révision du présent livre-blanc sera alors proposée.

Recommandations de mise en œuvre
Ce livre-blanc reprend les 55 critères d’accès de la priorité « Bronze » du « référentiel accessibilité » de la DGME et évalue MCMS et les technologies Sharepoint vis-à-vis de la prise en compte et du respect de chacun d’entre eux. Ces critères correspondent aux 55 critères du label AccessiWeb au niveau « Bronze » développés par l'association BrailleNet et publiés le 13 décembre 2003. Les seuls documents officiels et valides des critères AccessiWeb sont ceux mis en ligne sur le site Web d’AccessiWeb et, en particulier, les critères du label AccessiWeb de Bronze. Ce niveau d’évaluation permet de s’aligner sur la version 1.0 du Guide AccessiWeb publiée le 19 octobre 2005 dernier et qui propose une fiche pratique par critère AccessiWeb pour aider à le comprendre, à l'évaluer et à l'implémenter. Cette première version présente en effet à ce jour 55 fiches correspondantes aux 55 critères du niveau Bronze. Les fiches des critères des niveaux « Argent » et « Or » ne seront incluses qu’à partir de la version 2.0 du guide précédent. Une révision du présent livre-blanc sera alors proposée.

Les fonctionnalités disponibles en standard avec la plateforme Windows

Les fonctionnalités d’accessibilité de la plateforme Windows
Les emplacements clé au sein du système d’exploitation permettant de contrôler l’accessibilité Assistance Accessibilité et Utilitaires Démarrer/Tous les Programmes/Accessoires/Options Accessibilité Affichage et Apparence Démarrer/Panneau de Configuration /Options Accessibilité /Onglet Affichage Démarrer/Panneau de Configuration /Affichage Clavier et Souris Démarrer/Panneau de Configuration /Options Accessibilité /Onglet Clavier ou Souris Sons et Voix Démarrer/Panneau de Configuration /Options Accessibilité /Onglet Son Démarrer/Panneau de Configuration /Voix ou Sons et Périphériques Audio Raccourcis Clavier Démarrer/Aide

Les fonctionnalités d’accessibilité d’Internet Explorer
Ajustement de l’affichage Affichage /Taille du Texte Outils/Options Internet /Onglet Général / Accessibilité, Couleurs ou Polices Personnalisation de la barre d’outils Affichage/Barre d’Outils/ Personnaliser/Options Icônes Saisie Semi Automatique Outils/Options Internet /Onglet Contenu/Saisie Semi Automatique Personnaliser la présentation du contenu Web Outils/Options Internet /Onglet Avancé /Accessibilité

Les fonctionnalités d’accessibilité d’Office 2003
Ajustement en fonction de vos besoins et de vos préférences Amélioration de la lisibilité Affichage/Page Scroll pour augmenter la taille de la police Personnalisation des barres d’outils et des menus Outils/Personnaliser Utilisation des raccourcis clavier Automatisation des tâches Création de sites Web accessibles FrontPage 2003 Construction de formulaires accessibles

Un aperçu de Windows Vista™

Nouveau modèle d’accessibilité pour Windows - User Interface (UI) Automation
Le composant permettant l’accès programmé au nouveau modèle d’accessibilité de Windows Intégré en standard afin d’en permettre l’accès le plus large Expose les informations au sujet de l’IHM de manière cohérente Crée de nouvelles opportunités pour l’innovation Nouveaux périphériques de saisie Voix, Dance Pads, Tablette Gants de réalité virtuelle, contrôleurs Midi Nouveaux périphériques de sortie Surround sound systems Périphériques « haptiques » (avec retour de force) Création de solution multimodales

Interagit avec les éléments de l’IHM
Code permettant de contrôler automatiquement l’IHM d’une autre application Accès programmé permettant aux technologie d’assistance et aux programmes de test d’interagir avec les programmes Windows Récolte des informations au sujet de l’IHM et permet que des informations soient exposées à l’utilisateur final Interagit avec les éléments de l’IHM Cliquer sur un bouton, faire défiler nue liste, déplacer une fenêtre, etc. Injecte les frappes clavier et les mouvement de souris

L’enjeu de l’accès programmé
De manière cohérente et efficace, représenter une IHM qui est construite à partir de plusieurs technologies d’interfaces homme-machine différentes

L’approche aujourd’hui
Technologie d’assistance Méthodes WinForms Modèle Objet Texte API custom 2 … API custom 1 Modèle Objet SDM Messages & API Win32 … Application 1 Application 2 Custom 1 WinForms SDM Win32 Win32 Text Panel Custom 2

Nouvelle approche : UI Automation
Clients UI Automation Produits d’assistance Test Windows UI Automation UI Automation Providers Ancienne Application Nouvelle Application Windows Nouvelle Application Custom

Les 4 composants clés d’UI Automation
Automation tree – structure de l’interface utilisateur Explique où sont les choses sur l’écran Permet aux technologies d’assistance de présenter une structure qui fasse du sens pour leur utilisateur Properties – information importante à propos de l’interface utilisateur Explique quelle est l’information disponible sur un contrôle particulier de l’écran Name, Bounding Rectangle, Clickable point, etc. Control patterns – contrôle le comportement / le modèle d’interaction Explique ce que fait le contrôle Click, Scroll, Selection, Expand, Collapse… Events – notification of UI changes Quand quelque-chose change sur l’écran

« Facilité d’accès » Redéfinit l’accessibilité comme une « facilité d’accès » afin d’ouvrir de nouvelles opportunités de personnaliser la technologie pour chaque utilisateur Les 3 principales raisons indiquées par les utilisateurs pour utiliser les technologies/options d’accessibilité sont : Cela rend l’utilisation de l’ordinateur plus facile, Cela rend l’ordinateur plus commode, et Cela rend l’ordinateur plus confortable à utiliser

Les fonctions d’accessibilité de Windows XP
Panneau de configuration Accessibilité Paramétrage pour l’utilisateur, comme le réglage du contraste et des sons Assistant Accessibilité Utilitaires Lecteur d’écran Zoom d’écran Clavier sur l’écran

Evaluation du produit Etablissement d’un point de départ en conduisant des études d’utilisabilité Déterminer les besoins et les demandes des utilisateurs en observant les gens utilisant un produit ou un prototype Financement de l’Université de Washington pour déterminer la facilité avec laquelle les utilisateurs trouvent les fonctions d’accessibilité dans Windows XP Participants Personnes avec des déficiences visuelles ou de mobilité Personnes âgées Réalisation de tâches classiques Paramétrer un ordinateur Trouver une page Web Ecrire une lettre Gérer des fichiers

Les défis clés Manque de connaissance Difficile à découvrir
« Oh, je peux demander à mon ordinateur de faire çà ? » Difficile à découvrir « Je ne sais pas où trouver ces fonctionnalités. Je ne sais pas comment les mettre en route » Difficile à apprendre « Je ne sais pas comment utiliser ces fonctionnalités. Je ne peux me souvenir où les trouver »

Plusieurs points d’accès

Les objectifs du produit en termes d’accessibilité
Incarner les principes d’utilisabilité Apparence cohérente et en phase avec l’usage dominant tout en permettant l’utilisation d’un design innovant Fournir un point d’entrée cohérent et facile à découvrir

Processus de conception
Brainstorming - Conception - Retours Répéter…et Répéter ! Conduite d’une étude qualitative pour récolter les retours des utilisateurs à partir des premières directions produit Interview réalisé auprès de 31 habitants de New York Conduite d’une étude d’utilisabilité à partir d’un prototype interactif

Point d’entrée - Avant

Point d’entrée - Après

Questionnaire – Avant

Questionnaire - Après

Conclusion

Conclusion L’Internet est un formidable moyen pour les entreprises ou les administrations d'offrir de réels services à leurs usagers. Mais, un site Web ne doit pas être uniquement beau, mais efficace et utile. La notion d'accessibilité est en quelque sorte un label de qualité garantissant qu'un site Web est utilisable par tous, personnes handicapées comprises et quels que soient les moyens utilisés pour le consulter (PDA, téléphone portable, plage braille...). Nous avons tout à gagner à faire de l'accessibilité un critère explicite de qualité, à la fois parce que cela permettra à des personnes handicapées ou à mobilité réduite d’accéder facilement à des prestations ou services sans se déplacer, mais aussi parce que « madame ou monsieur tout le monde » trouvera les sites accessibles plus conviviaux et plus faciles d'utilisation. Par ailleurs, une simple réflexion sur les perspectives démographiques (l’évènement du « papy boom »), nous amène à penser que penser un développement informatique qui soit à la fois accessible et utilisable dévient une impérieuse nécessité avec l’avènement de seniors qui désirent rester actifs et le sont, pratiquent de plus en plus l’Internet mais peuvent souffrir davantage que les jeunes générations de déficits en matière de vision, de locomotion, etc.

Conclusion Une meilleure accessibilité est un élément essentiel
pour lutter contre la fracture numérique

Ressources

Ressources Site Web Accessibilité de Microsoft
Tutoriels étape par étape, produits et support Recherche Microsoft Assistive Technology Vendor Program Voluntary Product Accessibility Template (VPAT) Accessibilité de Microsoft Office System 2003 UI Automation Software Development Kit (SDK):

Questions ?

Microsoft France 18, avenue du Québec 91 957 Courtaboeuf Cedex
This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. © 2004 Microsoft Corporation. All rights reserved.

Outils Microsoft facilitant le développement de sites Web accessibles

Présentations similaires

Présentation au sujet: "Outils Microsoft facilitant le développement de sites Web accessibles"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Outils Microsoft facilitant le développement de sites Web accessibles

Présentations similaires

Présentation au sujet: "Outils Microsoft facilitant le développement de sites Web accessibles"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back