Javascript et accessibilité

Question

En tant que développeur Web, un certain nombre de projets sur lesquels je travaille relèvent des gouvernements et sont donc soumis aux lois 508 Accessibility, et parfois aux directives W3C accessibility. Dans quelle mesure JavaScript peut-il être utilisé tout en répondant à ces exigences? Dans ce sens, dans quelle mesure JavaScript, en particulier AJAX, utilise-t-il des paquets comme jQuery pour afficher des dialogues modaux, des popups, etc. supportés par des logiciels d'accessibilité modernes tels que JAWS, Orca, etc.? Dans le passé, la règle ressemblait à "Si cela ne fonctionne pas dans Lynx, cela ne fonctionnera pas pour un lecteur d'écran". Est-ce toujours vrai ou y a-t-il eu plus de progrès dans ces domaines?

EDIT: Le consensus semble être que javascript est très bien tant qu'il y a des fallbacks non-javascript, mais il semble encore incertain sur le support pour AJAX dans le logiciel de lecture d'écran. Si quelqu'un a une expérience spécifique avec cela, ce serait très utile.

Answer 1

Si l'accessibilité est votre principale préoccupation, toujours commencer un site web.! en utilisant conforme aux normes (choisissez une définition de type de document et respectez-la) HTML. S'il s'agit d'une application Web (soumissions de formulaires, etc.), assurez-vous que les formulaires fonctionnent avec HTTP GET et POST. Une fois que vous avez un site Web/une application complète, vous pouvez ajouter des morceaux de CSS et JavaScript tant que le site fonctionne encore, avec ou les deux désactivés.

Le concept le plus important ici est Progressive Enhancement. Vous ajoutez des cloches et des sifflets supplémentaires en utilisant CSS/JavaScript, mais votre site Web/application fonctionnera parfaitement bien sans non plus.

Un excellent outil pour tester 508, WAI, CSS off, JavaScript off essayer le plugin Web Developer pour Firefox.

Answer 2

Je pense que la réponse est vraiment dans la façon d'architecturer les choses. JQuery a la capacité d'être discret et donc accessible. L'astuce consiste à avoir une redondance autour de vos appels AJAX afin que les navigateurs sans JavaScript puissent toujours utiliser votre service. En d'autres termes, partout où vous avez des réponses JavaScript, des boîtes de dialogue, etc., vous devez avoir un équivalent dégradé.

Si vous avez l'accessibilité à l'esprit et que vous testez correctement les deux cas d'utilisation (JavaScript ou non JavaScript), vous devriez être capable d'écrire des applications qui répondent aux deux types d'audience.

Exemple ($ (document) appel .ready omis pour plus de clarté et de concision.

<script> 
    $("#hello").click(function(){ 
    alert("Hi"); 
    }); 
</script> 
<a href="/say_hello.htm" id="hello">Say Hello</a> 

Un exemple trivial mais, fondamentalement, cela n'évaluera l'événement JavaScript cliquez si JavaScript est pris en charge Dans le cas contraire, il interprétera comme un lien normal et aller à say_hello.htm - votre travail en tant que développeur est de faire en sorte que les résultats sont traités pour convenablement

Hope qui aide

Answer 3

L'amélioration progressive est certainement une voie, mais la discrétion n'est pas la finalité de l'accessibilité de JavaScript car les lecteurs d'écran ont tendance à utiliser les navigateurs comme base de travail. Étant donné que ces navigateurs prennent en charge JavaScript, les scripts sur votre page seront toujours exécutés. C'est un problème particulier avec AJAX car cliquer sur une partie de la page pourrait changer une autre partie de la page que le lecteur d'écran ne connaît pas. Cependant, au fur et à mesure de la maturation d'AJAX, des méthodes pour le rendre accessible apparaissent. Regardez dans le WAI-ARIA pour les méthodes modernes de rendre AJAX accessible, et Google's AxsJAX pour une bonne façon de l'implémenter.

---

Answer 4

JQuery a la capacité d'être discrète et donc accessible. L'astuce consiste à avoir une redondance autour de vos appels AJAX afin que les navigateurs sans JavaScript puissent toujours utiliser votre service. En d'autres termes, partout où vous avez des réponses JavaScript, des boîtes de dialogue, etc., vous devez avoir un équivalent dégradé.

Une façon de le faire pour réutiliser votre code, est d'avoir votre page « simple » d'appeler une « fonction » (ou tout ce que vous utilisez pour la logique côté serveur) qui peut être appelé par lui-même, de retour JSON ou XML .

Par exemple: /static/myform.asp (du côté du serveur, « comprend » la même logique que /ajax/myform.asp) cette façon, vous seriez en utilisant asp comme les modèles de django. Bien sûr, avec un cadre de sifflements et de sifflements complet, vous pouvez rendre cela beaucoup plus facile (pensez à avoir un html et un 'template' xml pour la même vue dans django), mais la même idée s'applique. Ceci étant fait, parcourir toutes les ancres sur document prêt en utilisant jQuery et ajouter des événements onclick en utilisant le lien de l'ancre, remplacer/static/ajax/pourrait vous faciliter la vie. Est-ce que quelqu'un peut penser à des raisons pour que cela soit trop lourd? Je voudrais savoir s'il y a une faille sérieuse sur cette "idée de design".

Answer 5

Voir

• http://juicystudio.com/article/making-ajax-work-with-screen-readers.php
• http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.php
• http://www.paciellogroup.com/blog/?p=15
• http://www-03.ibm.com/able/resources/ajaxaccessibility.html

Vous pouvez aussi jeter un oeil à FlashAid, bien qu'il soit loin d'être une solution parfaite. (Mais, si vous utilisiez l'amélioration progressive et n'utilisiez AJAX que lorsque Flash était présent et que l'utilisateur n'utilisait pas l'API d'accessibilité, vous pourriez avoir une solution raisonnable ... pour Windows.)

À long terme ARIA est la solution. Il est quelque peu supporté dans JAWS 10 (beta) et Firevox, mais il n'est certainement pas suffisant pour tous les utilisateurs d'aujourd'hui.