Une de nos applications Web vient de passer à 508 tests de conformité. Nous utilisons TinyMCE Version 3 pour le développement de contenu et je comprends que cela a généralement une bonne accessibilité. Cependant, l'une de nos pages contient 3 instances de TinyMCE ou plus chacune précédée d'un étiquette code> code> indiquant ce que l'instance TinyMCE est pour mais on nous dit que ce sont des étiquettes "implicites" quand elles devraient être "explicites" étiquettes (c'est-à-dire avec l'attribut Merci! P>
Solutions explorées à l'aide de Une solution possible que j'explore est englobant chaque instance TinyMCE avec un pour code>). Le problème est que TinyMCE Les instances ne sont que des iframes avec un assortiment complexe de "contrôles" de HTML personnalisés, alors que dans la mesure où je sais que l'étiquette / la technique ne fonctionne que avec des éléments de forme traditionnels. Quelle est la meilleure stratégie pour atteindre une étiquette «explicite» pour une instance TinyMCE? P>
étiquette code> +
pour code> qui ne fonctionne pas: pointant sur l'étiquette code> code> au début
textarea code> , pointant l'étiquette
code> sur le
iframe généré code>. p>
LEDGEND code> +
Tableau code> mais la teste de la sorte avec les mâchoires 9.0 Il ne semble pas faire de différence à moins que Le
champs code> contient des éléments de formulaire (par exemple,
entrée code>,
type = texte code>) et la mâchoire est en mode formulaires. P>
3 Réponses :
Si je lisais le Spécifications droite, le Par conséquent, je pense que la seule option valide est de pointer le document pour code> La propriété doit en effet indiquer un autre Control em> sur la même page, comme vous le souhaitez déjà. p>
pour code> attribuer sur le
Merci @pekka, j'avais essayé de pointer l'étiquette au Texarea, mais je pense que cela ne fonctionne pas car la Textarea est faite invisible (mâchoires, par exemple, ne lit généralement pas l'affichage: aucune ou visibilité: éléments cachés).
@Stephen Ouais, je pense que vous êtes un peu vissé avec ceci :) Je suppose que vous pourriez le faire indiquer l'ID de l'iframe quand TinyMCE l'a remplacé, mais ce n'est pas valide comme tel. Peut-être encore mieux que l'alternative, je ne peux pas juger que
Il existe une norme émergente pour ce type de problème: Aria (applications Internet riches accessibles). C'est toujours un brouillon de travail, mais le soutien commence à apparaître dans les lecteurs d'écran récents (Jaws 9, versions récentes de NVDA) lorsqu'il est utilisé avec des navigateurs récents (c.-à-d. 9, Firefox 3.6 (partielle) et 4.0, chrome).
Ce cas particulier, jetez un coup d'œil à Aria-label et Aria-labelledby a >. Ce sont des attributs qui seraient ajoutés à l'élément corporel du widget de TinyMce - ou à l'IFRAME, selon les deux que les deux se concentrent réellement lorsque l'utilisateur saisit des données. Ainsi: P> et dans le document TinyMCE: p> L'attribut aria-caché empêchera L'étiquette du document parent d'être lu et l'attribut Aria-label dans le document enfant (qui n'est pas visible) prendra sa place. Voila, un widget étiqueté visiblement et audible sans lecture redondante. P> Si vous utilisez Aria-caché de cette façon, faites très attention que le bit que vous cachez (ou un équivalent) est toujours disponible pour Lire quelque part d'autre. P> Cette solution ne fonctionnera que pour les personnes utilisant des navigateurs Web et des lecteurs d'écran qui soutiennent ARIA. Les personnes avec des lecteurs d'écran plus âgés ou des navigateurs auront de la chance, ce qui est longuement discuté dans l'article récent sur une liste d'une liste, l'accessibilité de Wai Aria . L'auteur fait une bonne affaire pour préférer des solutions HTML sémantiques traditionnelles dans la mesure du possible; Mais dans votre cas, je ne pense pas avoir une autre option. À tout le moins, l'ajout d'attributs Aria vous permettra de prétendre raisonnablement que vous avez effectué votre diligence raisonnable et faisait un effort de bonne foi pour le rendre aussi accessible que possible. P> bonne chance! P> Note aux futurs lecteurs: Les liens vers la spécification ARIA donnée ici font référence au projet de travail de septembre 2010. Si cela fait plus de quelques mois depuis lors, recherchez des spécifications plus récentes. P> P><body aria-label="Edit document">
. Ainsi, dans le document parent: p>
Utilisation des informations Martin fournies concernant l'attribut Il utilise le Fonction de rappel déclenchée après l'initialisation de l'éditeur. P> Il doit y avoir une étiquette code> ciblée à l'élément d'origine sur lequel TinyMCE appelle, dans mon cas un Aria-étiquette code>, j'ai écrit la ligne de code suivante qui fonctionne pour Tinycme 4:
textarea . EG: P>
<label for="id_of_textarea">Shiny wysiwyg editor"</label><textarea id="id_of_textarea"></textarea>