Résumé Ce document permet d’appréhender les évolutions de la plateforme SharePoint 2010 en termes d’accessibilité numérique et d’«utilisabilité»
télécharger 0.63 Mb.
|
à Afin de créer une bonne interface utilisateur, il ne devrait y avoir qu'un seul élément sur chaque page, et ce dernier doit correspondre au titre de la page. Utilisez autant de Les imagesLes images n'ont pas un nom qui leur est associé automatiquement. Les personnes qui ne sont pas en mesure de voir des images ou des graphiques sur une page Web ont besoin d'un moyen d'obtenir des informations sur ces images. La façon d'obtenir cette information est par le biais de l'attribut alt (également appelé « alt text »), associée aux éléments Les points à puce, les bordures et autres éléments décoratifs ne doivent être créées sous forme d'images, mais plutôt fait à l'aide de feuilles de style en cascade CSS. Les images d'arrière-plan sont automatiquement désactivées en mode Contraste élevé dans le CSS. Ces images décoratives sont mieux ajoutées avec CSS plutôt qu’avec des éléments N'utilisez pas de background-image CSS pour créer des images significatives, telles que des icônes. Comme indiqué ci-avant, les images d'arrière-plan sont désactivées en mode contraste élevé et aucun mécanisme n’est présent pour afficher une alternative textuelle. Les feuilles de style en cascade CSS sont destinées à la mise en forme visuelle ; le (X)HTML au contenu significatif. La règle 1.1.1 du standard WCAG 2.073 couvre tous les différents types d'images et fournit des conseils supplémentaires pour les alternatives textuelles. Vous pouvez également consulter l’article Creating Accessible Images74. Les alternatives textuellesToutes les images nécessitent une alternative textuelle. Ce qui est précisé comme alternative textuelle varie selon que l'image est fonctionnelle ou décorative dans le contexte de la page :
(X)HTML n'incluant pas par défaut une chaîne vide comme alternative textuelle pour les images, veillez donc à l’ajouter dans votre code. Déterminez quel devrait être l’alternative textuelle appropriée pour l'image considérée. Nous vous invitons à consulter l’article Appropriate Use of Alternative Text75. Les tableaux de donnéesPensez à la nature de l’information destinée à se retrouver dans un tableau de données et à la façon dont un utilisateur perçoit cette information. La création de tableaux de données accessibles nécessite l'application des éléments table appropriés, y compris et | . Les contenus de la balise sont associés à chaque cellule ; de ce fait, chaque fois qu’une technologie d’assistance lit une cellule, l'utilisateur se voit présenter les contenus associés. Assurez-vous de ne pas mettre d’informations dans une balise qui ne soit pas vraiment un en-tête et s'il existe une véritable ligne d'en-tête, utilisez une balise | et non une balise | . | Vous trouverez des informations spécifiques sur la création de tableaux de données accessibles dans la section Tableaux du standard HTML 4.01 du W3C76. Nous vous invitons également à consulter l’article Creating Accessible Tables77 à titre de complément. Une façon de rendre les tableaux de données souvent inaccessibles est par le biais de la création d'éléments improprement formaté, avec le texte mis en forme à l'intérieur. Veillez à utiliser les éléments de tableau de données correctes pour formater un tableau d'informations, ce qui permet à une technologie d’assistance de relayer l’information de lignes et colonnes dans le bon ordre et dans un format compréhensible. | Les éléments de formulaireDe nombreuses pages Web incluent des formulaires à remplir pour les utilisateurs ; SharePoint n’y fait pas exception. Qu’il s’agisse de donner des informations de paiement, de s’abonner à un bulletin d'information ou de répondre aux questions d’une enquête, il est crucial de rendre les éléments de formulaire accessibles aux utilisateurs qui en ont besoin. L'élément label joue un rôle important dans l'accessibilité des formulaires. L’association de cet élément avec chacun de vos contrôles fournit deux qualités accessibles sur la page pour les utilisateurs :
La façon dont le libellé est mise en œuvre est par le biais d'une association dans le code. Les propriétés label for et id sont d’importance dans le code. Le label for est associé à l'id, et non pas au nom. Même si vous ne souhaitez pas un libellé visible, vous pouvez utiliser un élément label pour provisionner un nom MSAA avec un display:none. De nombreux éléments de formulaire ont un attribut name. Cet attribut ne fournit pas le nom MSAA, qui est, dans les faits, fourni par le libellé associé, par exemple : Dans cet exemple, le nom MSAA est « Commentaires », et non pas « misc-field ». L'attribut name de l'élément input décrit le nom du champ envoyé au serveur lorsque le formulaire est soumis et n'a aucune relation avec le nom MSAA. Lorsque vous utilisez des contrôles de formulaire, assurez-vous que les label et id ont été implémentés pour eux. Les contrôles suivants devraient les inclure lorsque le code est écrit :
Nous vous invitons à consulter à titre de complément les articles Creating Accessible Forms78 et Usable and Accessible Form Validation and Error Recovery79. Certains menus et formulaires utilisent des boîtes déroulantes qui permettent aux utilisateurs de faire une sélection dans une liste d'éléments. Certains sont créés afin qu'un utilisateur clique sur la boîte déroulante et dès qu'ils sélectionnent un élément avec la souris il déclenche un événement automatiquement. Les utilisateurs de technologies d’assistance peuvent devoir passer par plusieurs options avant d'atteindre leur sélection désirée. Il est donc important de créer un bouton « Go » ou équivalent pour les utilisateurs de sorte que la navigation dans les sélections ne déclenche pas un événement indésirable. HTML a été initialement créé pour partager des informations entre utilisateurs sur des systèmes informatiques différents. Dans un format statique où les seules actions de l'utilisateur sont de cliquer sur un lien ou un bouton, les pages Web sont très accessibles (si codées correctement).  Figure . Nœud DOM dans une architecture Modèle-Vue-Contrôleur La figure précédente illustre un nœud DOM typique dans une architecture Modèle-Vue-Contrôleur. Sur le nœud, les données, ou le « modèle » qui doit inclure des informations sémantiques, sont séparées de la présentation d'interface utilisateur, la « vue ». Ici, l'élément document est géré par le navigateur basé sur le comportement par défaut de l'élément. Le comportement par défaut du navigateur au niveau de l'élément document constitue le « contrôleur ». Entre le nœud DOM et la technologie d'assistance, se trouve une boîte contenant le contrat fourni par le navigateur à la technologie d'assistance. Ce dernier comprend typiquement une information d'accessibilité disponible via une API d'accessibilité comme MSAA ou UI Automation (rôle, nom, état, caret, sélection, texte, hypertexte, information parent/enfant, autres relations, etc.). Pour (X)HTML, les informations d'accessibilité ainsi fournies dépendent uniquement, comme nous l’avons vu, du nom de l'élément et des attributs d'accessibilité qui correspondent à l’élément utilisé. Par exemple, le rôle accessible d'un tableau est « table ». Le développeur ou le concepteur fournit une description accessible en attribuant un attribut title. (X)HTML, cependant, n'a pas conçu avec le scripting ou l'interface utilisateur à l'esprit. Par voie de conséquence, l’accessibilité de DHTML (Dynamic HTML) et autres scripting nécessite une planification à l'avance pour exécuter des scripts de façon accessible sur une page Web (riche). Ainsi, dans la figure suivante, JavaScript agit comme le nouveau contrôleur :  Figure . JavaScript, le nouveau contrôleur sur le nœud DOM Il convient de noter que ce document utilise le terme JavaScript pour parler de scripts qui s’exécutent côté client. Il s’agit dans la pratique plus précisément du langage ECMAScript tel que spécifié par la norme ISO/IEC 16262:2002 (standard ECMA-262 ECMAScript Language Specification80). Cette dernière résout en effet les problèmes de compatibilité qui ont pu exister entre les différents langages de script : JavaScript, ECMAScript, Jscript. JavaScript remplace le comportement par défaut du navigateur sur le nœud DOM. Il manipule données, contenu et style en réponse à des événements causés par l'interaction de l'utilisateur pour produire un contenu personnalisé. Dans ce cas, les informations d'accessibilité par défaut ne sont plus valides et, par conséquent, le contrat est désormais non valide. La figure montre le contrat avec astérisques en face de rôle, état, actions, valeur, modifications de l'événement et relations. Ces astérisques représentent les erreurs potentielles en termes d'accessibilité et les lacunes dans le balisage de base. Ces lacunes résultent de l'incapacité à fournir les nouvelles données sémantiques nécessaires pour le contrat de support. Une technologie d’assistance qui utilise un cache est conçue pour mettre à jour son cache lorsqu'une navigation a lieu, par exemple une nouvelle page est chargée. Une navigation a lieu lorsque l'utilisateur clique sur un lien. Les technologies d’assistance écoutent l'événement onclick des liens. Si vous déclenchez votre script à partir d'un clic de lien, vous amenez la technologie d'assistance à recharger la page, mettre à jour le DOM avec les modifications apportées par votre script. Lorsque vous travaillez en DHTML, veillez à répondre à ces besoins : ancres (liens) et boutons, événements onclick, ordre de DOM et, le cas échéant, rôles ARIA. Une technologie d’assistance comme un lecteur d'écran lit les éléments dans l'ordre d'apparition dans la source, et non pas dans l'ordre d'apparition visuellement à l'écran. Tout comme l'ordre des éléments est important dans le code (X)HTML, l'ordre des éléments insérés dans le DOM est tout aussi important. La technologie d’assistance interagit avec les éléments dans le DOM, et non pas la représentation visuelle de la page. L’interface, c’est le DOM ! Le contenu positionné ou inséré doit être à sa place dans le déroulement de la source. En effet, le focus reste sur l’élément que l’utilisateur a activé. Par conséquent, le contenu inséré juste après cet élément sera le prochain pris en compte par les lecteurs d’écran et par la touche de tabulation. Utilisez pour cela l'élément L’article Multipage examples of JavaScript accessibility issues and solutions81 illustre un certain nombre de ces problématiques. Vous pouvez également consulter l’article Creating Accessible JavaScript82.
Lorsqu’un script effectue un appel dans une page DHTML, les informations sont envoyées au serveur, et une notification de mise à jour de statut est envoyée au client. Lorsque la page s'actualise, la technologie d’assistance écoute les mises à jour et recache la page pour l'utilisateur. Il s’agit d’appels synchrones. Les appels asynchrones seront abordés dans la section § 1.5.3 La notification des mises à jour asynchrones (AJAX) infra.
L'événement DOM onclick est déclenché lorsqu'un utilisateur clique sur un élément particulier. Comme c'est l'action par défaut MSAA pour un lien ou un bouton, il est également déclenché lorsque l'utilisateur appuie à la touche Entrée tandis que le focus est un de ces éléments. Une page Web (riche) accessible assure que tous les objets cliquables sont exposés comme éléments actionnables en les codant sous forme de liens avec des gestionnaires d'événements onclick. Les utilisateurs doivent pouvoir naviguer vers ces éléments à l'aide uniquement de la touche de tabulation et de les exécuter avec la touche Entrée. Si l'action conduit à ouvrir une nouvelle fenêtre ou à modifier la page de manière significative, veillez à indiquer clairement à l'utilisateur quelle action se produit (par exemple avec du texte ou une icône), afin que l'utilisateur sache à quoi s'attendre lorsqu’il clique sur le lien. Gardez à l'esprit que le seul événement que tout navigateur expose aux technologies d’assistance est l'événement onclick. Les personnes voyantes peuvent voir les événements comme un mouseover (survol avec la souris) ou key click, mais les autres utilisateurs doivent disposer d’autres façons d'accéder à la fonctionnalité, ou aux tâches, sur la page. L’évènement onkeydown et les autres événements peuvent fonctionner ou ne pas fonctionner pour la technologie d’assistance. L’évènement onclick est le seul événement sur lequel vous pouvez vous fier pour fonctionner avec toute technologie d’assistance. Gardez également à l'esprit que l'évènement onclick ne fonctionne pas bien pour les éléments de formulaire où les boutons radio ou cases à cocher sont inclus. Dans ces cas, un (X)HTML propre utilisant les attributs appropriés doit être appliqué. Vous pouvez vous reporter à la section § 1.5.1.2 Une sémantique (X)HTML correcte pour le contenu supra vis-à-vis des libellé et id des éléments de formulaire pour une information sur la façon de coder ceci correctement. Aujourd'hui, la plupart des designs les plus intéressants sur le Web incorporent AJAX, ou autres technologies de scripting asynchrone dans leurs pages. Les applications Web riches utilisant AJAX ont besoin de répondre aux questions d'accessibilité qui se posent pour des pages à l'aide de sémantique (X)HTML et de DHTML. La mise en œuvre d'AJAX ajoute, toutefois, une couche supplémentaire de complexité qui nécessite une bonne pratique de codage pour la rendre accessible. Qu’est-ce qui rend AJAX inhabituel du point de vue de l'accessibilité ? AJAX ne met à jour sur la page que les éléments qui ont changé. Ainsi, lorsqu’une seule partie de la page change, le processus de notification ignore le relai des informations mises à jour à la technologie d’assistance, le navigateur ne générant pas d’événement navigate dans ce cas (comme il pourrait le faire en réponse à un événement onclick sur une ancre). Pour l’utilisateur, la page devient inutilisable. Cette question constitue le cœur du problème pour rendre AJAX accessible. La façon de le faire (avec les navigateurs les plus récents) est par le biais de l'utilisation du standard en cours d’élaboration Accessible Rich Internet Applications (en abrégé WAI-ARIA ou plus simplement ARIA)83, un travail conduit par l'initiative pour l'accessibilité du Web (Web Accessibility Initiative ou WAI en abrégé) du W3C pour répondre aux problématiques introduites par l’usage des technologies DHTML, AJAX, SVG en spécifiant des extensions descriptives pour les applications Web riches. Le futur standard HTML 5.0 devrait incorporer ces fonctionnalités Lors de l'implémentation AJAX, veillez à garder à l’esprit les régions Live ARIA et autres rôles ARIA comme réponse à vos besoins en matière d'accessibilité. Nous vous invitons à consulter les articles Accessibility of AJAX Applications84 et Accessibility of Rich Internet Applications85 à titre de compléments.  Avant d’aborder ARIA, nous souhaitons mentionner la bibliothèque jQuery86 sous licence libre, qui est une bibliothèque JavaScript rapide et concise qui simplifie les interactions AJAX. Cette dernière s’insère bien dans un environnement où la présentation est fondée sur CSS ; elle est dite « CSS-Friendly ». Elle est souvent mise en œuvre avec la technologie ASP.NET (Cf. section § 1.5.5 Les considérations relatives à la technologie ASP.NET) et, par voie de conséquence, avec les technologies SharePoint. Comme nous l’avons décrit à la section § 1.2 L’utilisation de DOM et de Windows Automation 3.0, il n’est pas possible de modifier directement les valeurs des propriétés MSAA à partir d'une page Web, ce qui est vrai pour la plupart des navigateurs compte tenu du mappage en lecture seule effectué. La nouvelle technologie ARIA fait évoluer cette situation. ARIA est un ensemble d'attributs (X)HTML et de fonctions DOM connexes qui permet aux développeurs et concepteurs de manipuler directement les valeurs MSAA et UI Automation. Ainsi, par exemple, le rôle ARIA button permet de faire en sorte que MSAA retourne la valeur ROLE_SYSTEM_PUSHBUTTON lors de l’invocation de la méthode IAccessible ::get_accRole ; de même, le type de contrôle Button est retourné par UI Automation. De plus, avec UI Automation, l'attribut ARIA role original est également disponible à partir de la propriété AriaRole. Cette propriété renvoie la chaîne brute fournie dans le balisage avec aucun mappage appliqué. UI Automation propose également la propriété AriaProperties, qui retourne une collection de paires nom-valeur pour la plupart des états et propriétés ARIA. ARIA est implémentée, à des degrés divers, dans Internet Explorer 8, Firefox 2.0 et Firefox 3.x. La prise en charge d’ARIA dans Internet Explorer 8 (avec des extensions pour DHTML) est décrite dans les articles What's New for Accessibility in Internet Explorer 887, ARIA Implementation Guide for AT Vendors: Internet Explorer 888 et Mapping ARIA Roles, States, and Properties to UI Automation89. En plus d'offrir un accès direct aux valeurs MSAA, ARIA fournit aux développeurs un ensemble riche de rôles et propriétés que sont disponibles via le code (X)HTML pour les mappages MSAA réalisé le navigateur Web. On trouve ainsi :
SharePoint Product Team Blog |
