Chosen: Problèmes d'accessibilité avec Chosen

pièce pertinente de cette discussion :

Beaucoup trop besoin de travail. On dirait que l'accessibilité n'a pas été prise en compte à
tout dans ce widget, donc beaucoup de travail WAI-ARIA et JS serait nécessaire pour *
essayez * de rendre cela conforme aux WCAG 2.0.

Le plus gros problème, d'après un examen de 30 secondes avec FF6 / JAWS12, est que le
le composant est représenté comme un type d'entrée = texte suivi d'une liste non ordonnée
de toutes les options (243 pour les pays) que l'utilisateur doit parcourir pour accéder
même ignorer le terrain.

Le champ de texte de recherche pourrait utiliser une étiquette, pour commencer, mais c'est facile à corriger.

Un problème plus important est que les éléments de liste générés ne contiennent pas d'ancres... Les utilisateurs de lecteurs d'écran peuvent-ils agir s'ils savent à quoi servent les éléments de liste ?

C'est un très bon plug-in ! J'aime beaucoup la fonctionnalité.
Y aura-t-il un développement futur vers une meilleure accessibilité? Ajout de WAI-ARIA pour le rendre conforme aux WCAG 2.0 ???

Je viens de lire cet article sur le site de thefilamentsgroups. Les rôles ARIA pourraient se prêter à Chosen :
http://filamentgroup.com/lab/jquery_ipod_style_and_flyout_menus/

Par exemple : les résultats choisis UL auraient role="menu" aria-activedescendant="active-menuitem" appliqué et les résultats <li> auraient role="menuitem".
La zone de recherche dans la liste déroulante Chosen aurait probablement aussi besoin d'une sorte de rôle ARIA ??

@dotdreaming vous

Je pense que les rôles suivants devraient être utilisés :

• combobox .
• option

Je pense que ce serait vraiment cool si quelqu'un se plongeait vraiment dans la documentation WAI-ARIA et l'appliquait à son choix.

Si je peux trouver le temps, je peux le faire moi-même. Cela ne semble pas être très difficile à faire.

Un mouvement pour intégrer ARIA dans ce projet ?

Même s'il fonctionne avec la technologie d'assistance, il doit également être testé pour voir qu'il fonctionne également avec les utilisateurs de clavier uniquement.

Btw, c'est juste un moyen de vérifier les fruits à portée de main pour les améliorations d'accessibilité, mais WAVE a identifié quelques éléments assez basiques qui devraient être nettoyés -> http://wave.webaim.org/report?url=http%3A% 2F%2Fharvesthq.github.com%2Fchosen%2F&js=2

L'un de ces problèmes d'accessibilité a-t-il été résolu ? J'aime beaucoup l'utiliser sur le site principal de notre université, mais ces problèmes d'accessibilité me rebutent

+1 - Nous avons reçu des commentaires d'un utilisateur aveugle selon lequel les listes déroulantes Chosen sont difficiles à utiliser et ont des difficultés à sélectionner des options. Ils utilisent JAWS 14 comme lecteur d'écran.

J'ai essayé d'utiliser un clavier uniquement pour la navigation. La sélection d'éléments fonctionne très bien et intuitivement (bas pour ouvrir la liste d'un nouvel élément, haut/bas pour naviguer dans la liste, esc pour fermer la liste, entrée pour sélectionner). La suppression d'éléments de la sélection multiple était simple (retour arrière), mais la suppression d'une liste déroulante à sélection unique s'est avérée plus difficile. Il semble que, après avoir sélectionné un élément, je puisse appuyer pour ouvrir à nouveau la liste, puis naviguer vers le haut jusqu'à ce qu'aucune option ne soit sélectionnée (un peu comme une liste déroulante normale fonctionne si votre premier élément est vide comme le sont les exemples), mais je suis impossible d'appuyer sur Entrée pour sélectionner l'option nulle. Une méthode pour désélectionner complètement une option (ou au moins une option par défaut vide) serait très utile.

Je ne sais pas non plus si cela en vaut la peine, mais j'ai remarqué que les données sont toujours stockées dans le contrôle de sélection caché (je suppose que c'est ainsi qu'elles sont transmises au formulaire). Il pourrait être intéressant de mettre à jour la liste déroulante Chosen lorsque la sélection est également modifiée - je me demandais si cela satisferait aux critères 4.1.2 des WCAG, car les UA peuvent interagir avec le contrôle de sélection par programme et nous pourrions traiter Chosen comme une façade sur dessus à des fins d'accessibilité.

pour la deuxième partie, nous demandons de déclencher un listz:updated même lorsque vous modifiez la valeur du contrôle select par programme pour mettre à jour le choix.
Ceci est nécessaire car les navigateurs ne déclenchent pas d'événement lorsque la valeur est modifiée par programme pour en informer Chosen (et s'ils le faisaient, nous devrions toujours éviter les boucles infinies car nous le modifions également par programme)

Je vais étudier la possibilité d'ajouter l'accessibilité aujourd'hui. @marklagendijk Je pense que ce que vous avez mentionné est la meilleure façon d'utiliser un

Cela peut être utile, peut-être pas, mais nous avons des directives d'accessibilité strictes à suivre et avec la version 1.0.0, le testeur d'accessibilité de notre client est revenu avec les commentaires suivants :

1. le 'select' associé au 'label' a pour affichage : aucun ; et ainsi le
   'label' est effectivement orphelin. Le 'div class="chosen-container-single"' qui prend
   sa place car le contrôle de formulaire n'a pas de nom ou d'étiquette accessible par programmation.

2.Il n'y a pas de focus visible sur le faux menu déroulant.

1. Il n'y a pas de focus visible sur le lien dans la fausse liste déroulante.

Je l'utilise en conjonction avec le module Drupal Chosen. Nous avons également un testeur à l'aveugle qui a noté qu'une fois arrivé à l'entrée, il n'était pas conscient de pouvoir taper, ni les résultats renvoyés, y compris "Aucun résultat trouvé".

@marklagendijk
Tout progrès sur cette question. Je cherche à réintroduire le problème pour ajouter Chosen au noyau Drupal et c'est le principal bloqueur.

J'ai trouvé un très bon exemple de la façon dont cela peut être fait ici:
http://cookiecrook.com/test/aria/multiselect/listbox.html
Voici le javascript : http://cookiecrook.com/test/aria/multiselect/js/aria.js

Je pense que cela correspond presque exactement à la fonctionnalité de base choisie. Cela semble assez simple à mettre en œuvre à l'aide de la listbox et des propriétés aria multisélectionnables
http://www.w3.org/TR/wai-aria/roles#listbox
http://www.w3.org/TR/wai-aria/states_and_properties#aria -multiselectable

Je ferais un patch moi-même mais je ne suis pas si chaud chez js.

Mon RP lié ci-dessus fournit une solution via une approche beaucoup plus simple centrée sur les principes de l'amélioration progressive au lieu de se plonger dans la création d'un widget complètement accessible à partir de la base de code actuelle de Chosen. J'accueille tous les commentaires.

Pourquoi se concentrer sur ARIA alors qu'il n'est toujours pas correctement supporté par IE8 ? Malheureusement, ce navigateur vieux de 5 ans est toujours dans la liste des navigateurs courants. Cela signifie que lors d'une analyse d'accessibilité, une implémentation qui dépend d'ARIA échouera.

Pourquoi ne pas utiliser une méthode de secours qui désactive simplement l'ensemble choisi et fournit à l'utilisateur la sélection d'origine ? Cela pourrait être réalisé en ajoutant un lien (caché) qui utiliserait un petit morceau de code javascript qui désactive choisi.

Ressource concernant le support IE8 ARIA : http://www.w3.org/TR/WCAG20-TECHS/wai-aria_notes.html

Vous pouvez simplement effectuer une détection de navigateur/fonctionnalité et ne pas utiliser Chosen lorsque IE8 est utilisé.

@ Daniel15 Ce serait probablement même une solution plus facile. Merci d'avoir partagé vos pensées. Dans mon message, j'essayais simplement de souligner que la mise en œuvre d'ARIA (pour l'instant) ne signifie pas qu'il est accessible et prêt à être utilisé sur des applications qui doivent être conformes aux WCAG 2.0.

J'adorerais voir cela fonctionner. Les lecteurs d'écran et les utilisateurs de clavier uniquement ont vraiment besoin d'accéder à ces champs. Je ne suis pas tellement concerné par IE8 mais au moins une solution pour les navigateurs modernes serait acceptable. J'aime bien l'idée de repli d'IE8. Il semble qu'il y ait deux bons PR - j'aimerais voir l'un d'eux fusionner.

un gros +1 s'il vous plait

+1 (+) Nous devons l'avoir dans Chosen. C'est un problème

aria-label (propriété)

Définit une valeur de chaîne qui étiquette l'élément actuel. Voir aussi aria-labelledby.

Le but de aria-label est le même que celui de aria-labelledby. Il fournit à l'utilisateur un nom reconnaissable de l'objet. Le mappage d'API d'accessibilité le plus courant pour une étiquette est la propriété de nom accessible.

Si le texte de l'étiquette est visible à l'écran, les auteurs DEVRAIENT utiliser aria-labelledby et NE DEVRAIENT PAS utiliser aria-label. Il peut y avoir des cas où le nom d'un élément ne peut pas être déterminé par programmation à partir du contenu de l'élément, et il y a des cas où fournir une étiquette visible n'est pas l'expérience utilisateur souhaitée. La plupart des langages hôtes fournissent un attribut qui pourrait être utilisé pour nommer l'élément (par exemple l'attribut title en HTML [HTML]), mais cela peut présenter une info-bulle de navigateur. Dans les cas où une étiquette visible ou une info-bulle visible est indésirable, les auteurs PEUVENT définir le nom accessible de l'élément en utilisant aria-label. Les agents utilisateurs donnent la priorité à aria-labelledby sur aria-label lors du calcul de la propriété de nom accessible.

@Natshah Pouvez-vous faire une pull request avec le changement ?

@Natshah en fait, pouvez-vous consulter https://github.com/harvesthq/chosen/pull/2047 pour voir s'il l'implémente de la bonne manière ?

Salut,

J'ai résolu ce problème pour mon cas sur ce lien
https://www.drupal.org/node/2384865

Merci.

Récompense :)

Oui. C'est ce qui devrait être comme quelque chose comme dans le code suivant. .

      if (this.is_multiple) {
        this.container.html('<ul class="chosen-choices"><li class="search-field"><input type="text" aria-label="' + this.form_field_jq.parents("label") +'" value="' + this.default_text + '" class="default" autocomplete="off" style="width:25px;" /></li></ul><div class="chosen-drop"><ul class="chosen-results"></ul></div>');
      } else {
        this.container.html('<a class="chosen-single chosen-default" tabindex="-1"><span>' + this.default_text + '</span><div><b></b></div></a><div class="chosen-drop"><div class="chosen-search"><input type="text" aria-label="' + this.form_field_jq.parents("label") +'"  autocomplete="off" /></div><ul class="chosen-results"></ul></div>');
      }

Mais on peut utiliser ce code :

        $(".views-exposed-widget").each(function( index, element ) {
           $(this).find('.form-type-select .chosen-container input').attr("aria-label" ,$.trim($(this).find('label').text()));
        });

Merci.

Récompense :)

Une mise à jour pour ceci? Nous avons récemment implémenté choisi et avons reçu des commentaires d'utilisateurs utilisant la technologie d'assistance "Jaws" selon lesquels ils ne peuvent pas du tout utiliser les champs de sélection.

Cela semble être une question importante à examiner. Y a-t-il eu un mouvement sur ce front ?

Rien à ma connaissance, malheureusement, il est très difficile de reproduire les problèmes étant donné les combinaisons massives de technologies d'assistance avec les navigateurs et les systèmes d'exploitation... Normalement, tant que vous pouvez naviguer au clavier + vous avez une implémentation ARIA correcte, cela devrait fonctionner dans la majorité des cas.

Pour une solution rapide, j'ai recouru à ce que les lecteurs d'écran utilisent au moins le champ de sélection d'origine. Pour cela, au lieu de masquer l'élément select, j'ajoute une classe screenreaders-only et aria-hidden:true sur le conteneur choisi généré.

Ainsi, dans les chosen.jquery.js lignes 599 to 605 ressemblent à ceci :

container_props = {
        'class': container_classes.join(' '),
        'style': "width: " + (this.container_width()) + ";",
        'title': this.form_field.title,
        // hide widget for screen-readers
        'aria-hidden': 'true'
};

Et la ligne 616 ressemble à ceci :

      // instead of hiding the original select field, adding the .sr-only class to keep it accessible for screen readers
      this.form_field_jq.addClass('sr-only').after(this.container);

Ce n'est pas une solution parfaite, car la sélection cachée et le widget peuvent être focalisés au clavier, mais c'est bien mieux que d'avoir un widget inaccessible.

Cela a fonctionné pour moi.
J'ai suivi tous les conseils ci-dessus et j'ai modifié la ligne suivante :

this.container.bind('mousedown.chosen', function(evt)   // around line 630

à:

this.container.bind('mousedown.chosen keydown.chosen', function(evt)

Merci

Essayez si ça marche. La structure devrait être ainsi. :)

J'ai essayé d' ajouter des éléments ARIA sur la base du travail effectué par

J'ai une branche disponible ici qui fait ce qui suit :

Étiquettes ARIA et autres attributs utiles

• Ajoute les éléments aria suivants à la zone de saisie de recherche
  
  
  
  • role="combobox"
  
  
  • Utilisé pour indiquer que les utilisateurs peuvent taper pour sélectionner une option ou ajouter de nouveaux éléments à une liste
  
  
  • aria-haspopup (implicite lors de l'utilisation du rôle combobox)
  
  
  • Utilisé pour indiquer que cette boîte a un menu associé
  
  
  • aria-développé
  
  
  • Obligatoire lors de l'utilisation de la combobox, indique que la liste des résultats est visible ou masquée
  
  
  • L'état doit être mis à jour dynamiquement au fur et à mesure que le champ choisi est activé/désactivé
  
  
  • aria-activedescendant="id_of_highlighted_option"
  
  
  • Utilisé pour indiquer quelles options est la valeur actuellement sélectionnée
  
  
  • Cela doit être mis à jour lorsqu'une nouvelle option est sélectionnée
  
  
  • aria-owns="id_of_list_of_options"
  
  
  • Indique la liste des choix auxquels cette zone de recherche est liée
  
  
  • aria-autocomplete="list"
  
  
  • « Si un auteur définit la valeur d'aria-autocomplete d'une zone de liste déroulante sur 'liste', les agents utilisateurs DOIVENT exposer les modifications apportées à l'attribut aria-activedescendant sur la zone de liste déroulante pendant que la zone de liste déroulante reste focalisée. Si une modification de l'attribut aria-activedescendant se produit pendant que la zone de liste déroulante est ciblé, les technologies d'assistance DEVRAIENT alerter l'utilisateur de ce changement, par exemple, en prononçant l'alternative textuelle du nouvel élément descendant actif. Les auteurs DEVRAIENT associer le champ de texte de la zone de liste déroulante à sa zone de liste en utilisant aria-owns."
  
  
  • aria-labeledby="id_of_field_label"
  
  
  • Il s'agit de l'ID de l'élément d'étiquette de formulaire choisi en remplacement
  
  
• Ajoute les attributs suivants à la liste des options
  
  
  
  • identifiant
  
  
  • Un identifiant simple basé sur l'identifiant du champ de formulaire à cibler par l'attribut aria-owns dans la zone de saisie de la recherche
  
  
  • role="listbox"
  
  
  • "Un widget qui permet à l'utilisateur de sélectionner un ou plusieurs éléments dans une liste de choix."
  
  
• Ajoute les attributs suivants à chaque option individuelle dans la liste des options
  
  
  
  • identifiant
  
  
  • Un identifiant simple basé sur l'index de l'option dans la liste et l'identifiant du champ de formulaire à utiliser par l'aria-activedescendant qui indique l'élément actuellement sélectionné
  
  
  • role="option"
  
  
  • Un élément sélectionnable dans une liste de sélection.
  
  
  • aria-occupé
  
  
  • La raison pour laquelle nous en avons besoin est que lorsque Chosen est initialisé sur un champ, il _ne_ crée pas_ la liste d'options tant que le champ n'est pas activé pour la première fois.
  
  
  • C'est un problème pour la technologie d'assistance, ainsi que pour les scanners qui recherchent des problèmes d'accessibilité. Étant donné que la zone de recherche (role="combobox") déclare maintenant qu'elle possède une liste (aria-owns="id_of_list_of_options"), la liste (notre liste de résultats) _doit_ contenir des options OU être déclarée occupée afin de se conformer à la spécification.
    
    
    
    
    
    • Je ne suis même pas sûr à 100% que ce soit la bonne décision. Cela empêche certainement les champs d'être signalés par les scanners, mais ceux-ci ne sont pas entièrement occupés, nous n'avons tout simplement pas encore construit les options.
    
    
    
  
  
  • J'espère que quelqu'un avec plus d'expérience A11Y pourra peser là-dessus.
  
  
  • J'ai également envisagé une approche plus radicale, qui consiste à construire la liste des résultats lorsqu'un champ est activé pour la première fois, mais qui implique d'ajouter un nouveau déclencheur à Chosen.
    
    
    
    
    
    • Ce déclencheur était essentiellement un passage à la méthode winnow_results, qui construisait les résultats de la recherche (toujours cachés), mais il rendait les scanners heureux.
    
    
    
  
  

État de gestion

• Gestion de l'attribut aria-expanded
  
  
  
  • Afin d'indiquer quand les résultats de la recherche doivent être pertinents pour la technologie d'assistance, nous devons basculer l'attribut aria-expanded lorsque les champs sont activés/désactivés.
  
  
  • La façon la plus simple de le faire (AFAIK) est d'ajuster l'attribut pendant les méthodes close_field et activate_field .
  
  
  • Un simple passage de vrai à faux ou de faux à vrai dans chacune de ces méthodes est suffisant pour maintenir l'état à jour
  
  

Je vais commencer à utiliser cette version sur plusieurs de nos projets, et je continuerai à mettre à jour ma branche avec les changements au fur et à mesure que nous aurons un aperçu plus détaillé de nos projets à partir d'une vue A11Y.

Merci à tous ceux qui ont lu jusqu'ici, je sais que c'est beaucoup et s'il vous plaît, si vous avez des commentaires, faites le moi savoir ! Je veux pousser ça le plus loin possible.

@cooperfellows, veuillez ouvrir une pull request avec vos modifications

@stof Done, mais comme je l'ai dit, je ne suis pas un expert A11Y et je prévois de faire d'autres tests. Je voulais juste partager autour de mon premier passage stable à ce sujet.

Y a-t-il une mise à jour "officielle" avec cela? Des modifications ont-elles été apportées sur la base des efforts de

La raison pour laquelle je pose la question est que nous obtenons de plus en plus d'utilisateurs de Jaws qui signalent le widget comme inutilisable, rendant effectivement le formulaire qu'ils regardent inutilisable.

Nous pouvons reproduire, si heureux d'aider / partager des exemples si cela peut aider ?

La demande d'extraction a été faite (il y avait quelques problèmes mineurs qui avaient été résolus après coup) mais rien ne s'est encore produit. La branche que j'utilise en production en ce moment est ici :

• https://github.com/cooperfellows/chosen/tree/a11y-updates

J'aimerais quand même avoir d'autres retours. Je n'ai pas Jaws, je m'appuie donc sur les audits de divers outils en ligne.

Donc, cette branche est essentiellement la production actuelle plus vos modifications, ou une version précédente avec des modifications récentes non encore fusionnées ?

(Merci d'ailleurs)

Oui, c'est vrai @wcndave. Bien que le PR puisse vraiment utiliser d'autres yeux pour l'examen.

@cooperfellows Je suis heureux d'aider aux tests d'accessibilité car je dois porter une implémentation choisie existante dans une nouvelle version qui doit répondre aux WCAG 2.

Une mise à jour sur votre pull request ?

Question idiote - avez-vous une version JavaScript compilée que je peux télécharger ?
Ou dois-je installer coffeescript et compiler moi-même ?

@KITSKevinBonett Merci pour votre aide !

Ci-joint un zip de la version de type jquery et proto, à la fois compressé et non compressé.

compilé-a11y-chosen-jquery-proto.zip

@cooperfellows C'était rapide. Je vais ajouter à notre projet, faire des tests et vous tenir au courant...

@KITSKevinBonett Ya, je cherche à en savoir plus, car je ne suis pas un expert A11Y. Ainsi, tout retour (dur et positif) est apprécié.

Salut @cooperfellows - J'ai examiné votre implémentation - très bien en effet.

Certains problèmes peuvent ne pas être (facilement) résolus en raison d'incompatibilités entre le lecteur d'écran et le navigateur.

J'ai documenté mes conclusions dans la pièce jointe. J'ai fait 1 ou 2 recommandations mineures qui, j'espère, vous seront utiles.

_METTRE À JOUR_

1. Certains de mes commentaires mentionnaient des fonctionnalités locales à notre implémentation - je les ai supprimées.
2. Problème de saisie à l'intérieur de "combobox" et d'appuyer sur ENTRER - notre formulaire d'envoi n'est pas activé - encore une fois, il s'agit d'un problème d'implémentation locale.
3. Le ZIP ci-dessous a été mis à jour pour supprimer (1) et (2).

aria-chosen-plugin.zip

Salut @cooperfellows - mon audit était-il logique ?

Salut @KITSKevinBonett Je suis parti une semaine en vacances. J'y jetterai un œil dès que je serai au courant de mes autres travaux. Merci pour le retour, je suis sûr que c'est utile.

@KITSKevinBonett Merci pour l'audit, cela semble assez complet. J'ai divisé mes réflexions en fonction des sections de la vérification telles que vous les avez présentées.

Balisage HTML généré par le plugin

• Y a-t-il des commentaires ici ? Ou montrez-vous simplement ce qui est généré ?

Comportement du clavier uniquement

• "Cependant, lorsque l'option a été sélectionnée, le focus du clavier se perd à nouveau sur la tabulation."
  
  
  
  • Je pense que cela pourrait être résolu en activant et en désactivant l'attribut aria-hidden lorsque cet élément est rendu visible/masqué ?
  
  
  • Je vais étudier cette approche.
  
  
• "Problèmes CSS désactivés"
  
  
  
  • La sélection standard est visible
  
  
  • Je ne peux pas recréer ça, pouvez-vous me donner une capture d'écran ou une projection d'écran ou quelque chose du genre ?
  
  
  • Aucun repère visible lors de la mise en surbrillance des résultats avec le clavier.
  
  
  • Nous pourrions envelopper le texte de l'élément actuellement mis en surbrillance dans une balise <em> , qui est en italique (au moins dans Chrome).
    
    
    
    
    
    • Le problème potentiel ici est que la recherche utilise également <em> pour indiquer les correspondances de texte, donc je crains qu'elles n'entrent en conflit les unes avec les autres.
    
    
    
  
  

Lecteurs d'écran

• Je n'ai pas accès à JAWS, je ne pourrai donc pas faire grand-chose ici. Je ferai un essai quand j'aurai plus de temps pour voir ce que je peux trouver.
• Les lecteurs d'écran sont le domaine pour lequel j'apprécierais vraiment un peu plus d'aide, alors merci pour la ventilation détaillée.

Aria Pensées

• Je peux supprimer l'attribut haspopup, comme vous l'avez noté, c'est redondant.
• La raison pour laquelle j'ai ajouté aria-busy est que, par défaut, Chosen ne génère aucun élément de liste dans les div cachés jusqu'à ce que le focus soit placé.
  
  
  
  • Cela signifie que l'élément role="listbox" n'a pas d'options par défaut, ce qui me posait des problèmes lors de l'analyse avec des outils. En ajoutant l'élément aria-busy au début, il est ignoré par ces outils.
  
  
  • La raison du problème est qu'un élément listbox _doit posséder_ un élément option ( source )
  
  
  • Il est supprimé la première fois que la liste est remplie, cela m'a donc semblé être une situation sans danger et sans faute.
  
  
• L'ajout d'aria-selected semble être une étape évidente, je ne peux pas croire que j'ai raté ça. Merci de l'avoir attrapé.
  * Pensées de clôture *
  Avez-vous rédigé vous-même le code HTML de cet audit ou un outil l'a-t-il créé pour vous ? C'est très utile alors merci encore.

@cooperfellows - réponses à vos questions :

balisage HTML

• Montrer simplement ce qui est généré pendant chaque phase du comportement du plugin.

Comportement du clavier

• Le « focus perdu » est uniquement dans Firefox. Vous pouvez ajouter tabindex="-1" pour empêcher le focus, puis le supprimer à nouveau. Alors vous n'auriez pas besoin d'ARIA.

CSS désactivé

• Fondamentalement, le SELECT d'origine est visible sur la page et utilisable avec UP | Flèches vers le BAS car le comportement par défaut du navigateur affiche les différentes options lorsque vous les parcourez.
• Le code HTML rendu par le plugin est également visible, mais la liste déroulante n'indique pas quelle "option" est mise en surbrillance.
• Vous avez suggéré d'utiliser un EM. Utilisez STRONG à la place - il a plus de sens sémantique que EM en HTML5. Voir http://html5doctor.com/ib-em-strong-element/
• Mais je ne pense pas que ce soit un problème majeur car les utilisateurs peuvent toujours utiliser le SELECT.
• Voir capture d'écran

Lecteurs d'écran

• C'est une question difficile car les résultats varient en fonction de la combinaison de navigateur et de lecteur d'écran utilisée et des versions.
• Ce que je dirais, c'est que vos mises à jour d'accessibilité au plugin en termes de rôles/états/propriétés ARIA sont alignées sur les recommandations W3C/WAI. C'est donc une bonne nouvelle. :)
• Il appartient aux fabricants de navigateurs et de lecteurs d'écran de s'assurer que leurs logiciels s'y conforment.

ARIA

• Votre explication pour "aria-occupé" est logique. Même s'il était obsolète, cela ne posera aucun problème.
• Auditer le HTML. Fabriqué à la main. J'ai construit une bibliothèque de composants d'interface utilisateur / un guide de style de vie pour l'entreprise pour laquelle je travaille, donc j'ai juste utilisé des composants à partir de là. Cela n'a pas pris longtemps. La partie la plus difficile a été de réécouter toutes les sorties du lecteur d'écran pour m'assurer que j'avais tout capturé correctement.

J'espère que tout cela vous aidera avec votre pull request. Vous avez fait un excellent travail avec l'A11Y. :)

Bonjour,

Je suis aveugle. J'ai testé le travail de @cooperfellows avec JAWS. Cela fonctionne parfaitement. L'option sélectionnée est prononcée au fur et à mesure que je fais défiler les options.

Des nouvelles sur la fusion de ceci dans le maître?

Dans mon travail quotidien, j'utilise MISP (Malware Information Sharing Platform - https://github.com/MISP/MISP), dont les développeurs ont récemment décidé d'utiliser "chosen" pour les combos de saisie semi-automatique. C'est devenu un cauchemar pour moi.

Merci d'avance pour votre aide.

Après quelques tests, je peux confirmer que la version compilée (archive .zip) publiée ci-dessus (le 1er juillet 2016) fonctionne.

Cependant, lorsque j'essaie la branche de @cooperfellows , ou lorsque je clone la branche de

Salut @obert01 , merci beaucoup d'avoir jeté un coup d'œil à cela en utilisant JAWS, c'était un gros morceau qui me manquait pendant mon travail.

Cette branche est bien obsolète par rapport à la branche Harvesthq/master actuelle, je devrai probablement revoir les modifications et ajuster mon PR afin de remettre les choses en état de marche.

Je vais essayer d'y arriver avant la fin du mois, je suis assez soutenu au travail en ce moment.

J'adorerais que l'un des contributeurs y envoyer un ping à

Merci beaucoup.

Pour information, je peux tester avec toutes les combinaisons de lecteurs d'écran JAWS et NVDA, avec le navigateur suivant : Internet Explorer 11, Google Chrome, Firefox ESR, Firefox Standard, Microsoft Edge.

Des progrès là-dessus ?

Je suis désolé d'insister, mais mon travail quotidien souffre de ce manque d'accessibilité.

De plus, l'ajout de la prise en charge de l'accessibilité permettrait à Chosen d'être utilisé dans les sites Web du secteur public / de l'administration, car la réglementation dans de plus en plus de pays va dans ce sens.

Merci

Salut,
Nous avons une application qui a utilisé choisi et maintenant nous devons prendre en charge l'accessibilité, mais en passant par là, ce que je peux voir, c'est qu'elle n'a pas encore été fusionnée. Ce sera vraiment utile si @cooperfellows peut finaliser cela et fusionner s'il vous plaît.

Salut @obert01 et @csmuthukuda ,

Je viens de faire des mises à jour pour que mes relations publiques soient à jour avec la dernière version de Chosen, veuillez jeter un œil ici :
https://github.com/harvesthq/chosen/pull/2596

Vous pouvez obtenir une copie de mon référentiel fork et tester de votre côté. J'aimerais avoir des retours dans la vraie vie.

Il a passé tous les contrôles TravisCI, mais je ne pense pas qu'ils couvrent les problèmes A11Y. Laissez-moi savoir ce que vous pensez.

Salut @cooperfellows ,
Merci beaucoup pour votre dévouement à garder cela en vie. Je vais tester ça et vous ferai part de mes retours. J'espère vraiment que les propriétaires envisageront de fusionner cela avec le maître. C'est désormais une exigence obligatoire.

Merci @csmuthukuda J'aimerais qu'il soit fusionné dans ....

@pfiller @stof @tjschuck @koenpunt , que puis-je faire pour aider à ce que cela soit examiné ? C'est vraiment une pièce manquante à un système par ailleurs incroyablement génial.

Salut @cooperfellows ,

J'ai testé votre excellent travail avec la plupart des navigateurs Web actuels et les lecteurs d'écran JAWS et NVDA. Merci !

Faire défiler les options avec le clavier fonctionne bien : la rétroaction vocale et braille est parfaite, ce qui signifie que tous les attributs ARIA sont bien définis. Cependant, lorsque j'appuie sur ENTER pour choisir une option, rien ne se passe. Je n'ai pas assez d'expérience avec JavaScript pour déterminer si le problème vient de Chosen, ou s'il est présent dans l'application qui l'utilise.

Pour reproduire, essayez de choisir une option dans une liste déroulante Chosen uniquement à l'aide du clavier : TAB pour focaliser la liste déroulante, touches fléchées pour parcourir la liste, ENTRÉE pour sélectionner.

Encore une fois, je vous remercie beaucoup.

Merci pour cette information @obert01. Je vais regarder et voir ce que je peux trouver.

@obert01 Pouvez-vous essayer d'utiliser ce violon JS pour confirmer qu'il fonctionne/ne fonctionne pas ? Ce violon charge la version jQuery compilée de mon dernier commit.

• https://fiddle.jshell.net/cfellows/r5kp1udb/8/show/light/

Je peux naviguer dans cette liste déroulante à l'aide de mon clavier (Chrome Latest), mais je n'exécute PAS de lecteur d'écran.

Laissez-moi savoir ce que vous pensez.

Salut @cooperfellows ,

Pas de problème avec votre JS Fiddle. Ainsi, je suppose que le problème est dû à la façon dont Chosen est utilisé dans MISP (https://www.misp-project.org/).

Je vais vérifier cela avec l'équipe du projet MISP.

Merci

Merci @obert01. S'il vous plaît, faites-moi savoir ce que vous découvrez. Cela pourrait indiquer une incompatibilité avec une configuration spécifique de Chosen, donc s'il y a un moyen pour moi de voir comment MISP l'utilise, je peux essayer de jeter un œil à leur implémentation.

Est-ce que choisi est utilisé quelque part publiquement ?

@cooperfellows pouvez-vous s'il vous plaît me donner une nouvelle version avec les dernières modifications que je ne sais pas comment la construire.

@obert01 @cooperfellows Je viens d'essayer le Fiddle avec NVDA, il semble que la navigation au clavier fonctionne parfaitement (y compris la sélection avec la touche ENTER). Cependant, lorsque je navigue à l'aide des touches fléchées haut et bas, le lecteur d'écran lit "________non sélectionné", c'est-à-dire "Bermudes non sélectionné". Est-ce le comportement attendu?

J'ai le même problème que @woenlee. Ce n'est pas si nocif. Mais peut-être que la façon dont l'attribut "sélectionné" est défini sur l'élément sélectionné doit être vérifiée.

Quel est le comportement attendu lorsque vous « entrez » et « quittez » un élément de liste ? Lorsque
vous naviguez vers un nouvel élément, s'il lit le nouveau
Objet? Annonce-t-il également ce qui n'est plus sélectionné ? @obert01 @woenlee

Le dimanche 25 août 2019 à 12h18 Olivier BERT [email protected]
a écrit:

J'ai le même problème que @woenlee https://github.com/woenlee . Ce n'est pas
si nocif. Mais peut-être, la façon dont l'attribut "selected" est défini sur le
l'élément sélectionné doit être coché.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/harvesthq/chosen/issues/264?email_source=notifications&email_token=ABT3ZTIESGLX6IYW4BF2QCLQGKWDVA5CNFSM4AATGGB2YY3PNVWWK3TUL52HS4DFVREXG43VMTYVBW63LNMV5WWWYZLOZGOD87T
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABT3ZTMH2KUYYE7HNO2UGH3QGKWDVANCNFSM4AATGGBQ
.

--
~ Cooper

@cooperfellows Après avoir exécuté quelques tests d'accessibilité de hache, il semble que j'aie trouvé un bogue dans votre RP, ce qui explique pourquoi il le faisait. À la ligne 342 de Abstract-chosen.coffee, l'entrée a 2 rôles qui lui sont assignés, "combobox" et "listbox".

<input class="chosen-search-input" type="text" autocomplete="off" aria-expanded="false" aria-haspopup="true" role="combobox" aria-autocomplete="list" autocomplete="off" role="listbox" /> </div> <ul class="chosen-results"></ul>

Après avoir donné le

Payer les clients de Harvest ici et tester pour être accessible en interne s'est heurté à cela. L'accessibilité est un must, et nous quitterons Harvest si cela n'est pas résolu, si un responsable avec Harvest ne montre pas au moins un certain soutien à cela bientôt.

@obert01 Pouvez-vous essayer d'utiliser ce violon JS pour confirmer qu'il fonctionne/ne fonctionne pas ? Ce violon charge la version jQuery compilée de mon dernier commit.

• https://fiddle.jshell.net/cfellows/r5kp1udb/8/show/light/

Je peux naviguer dans cette liste déroulante à l'aide de mon clavier (Chrome Latest), mais je n'exécute PAS de lecteur d'écran.

Laissez-moi savoir ce que vous pensez.

@cooperfellows
Je testais ce JS Fiddle avec JAWS 2019 et j'ai expérimenté quelque chose de légèrement différent lors de la navigation dans les options avec les touches fléchées haut et bas.
Sur Google Chrome 71.0.3578.98 :
JAWS ne lirait pas la valeur actuelle en surbrillance à moins que la liste ne fasse un défilement/rendu. c'est-à-dire si la liste s'affiche

<option selected="selected" value="United States">United States</option>
<option value="Afghanistan">Afghanistan</option>
<option value="Albania">Albania</option>
<option value="Algeria">Algeria</option>
<option value="American Samoa">American Samoa</option>
<option value="Andorra">Andorra</option>
<option value="Angola">Angola</option>
<option value="Anguilla">Anguilla</option>
<option value="Antarctica">Antarctica</option>

9 options, JAWS ne lit pas l'option en surbrillance lorsque vous appuyez jusqu'à ce que vous arriviez à la 10e option àAntigua-et-Barbuda . La boîte fait un petit défilement automatique pour mettre en surbrillance Antigua-et-Barbuda, puis lit l'option.

Sur IE 11.0.9600.19463 : La navigation avec les touches fléchées semble lire correctement l'option en surbrillance actuelle en montant et en descendant. Ne nécessite pas une sorte de rendu.

J'aimerais savoir si quelqu'un d'autre a vécu cela. @obert01 @woenlee

Bonjour et merci pour votre travail.

Malheureusement, cela ne fonctionne pas correctement. Il est extrêmement difficile à décrire, car le comportement change en fonction du navigateur ou du lecteur d'écran utilisé.

Je pense que certaines propriétés aria ne sont pas présentes ou ne sont pas mises à jour. Voici les problèmes généraux que je rencontre :

• Problème de défilement : lorsque je flèche vers le bas et que j'arrive à la fin de la liste des éléments visibles, je dois appuyer deux fois sur la flèche vers le bas pour mettre l'accent sur l'élément suivant.
• Lorsque j'appuie sur ENTER pour sélectionner un élément, la mise au point n'est pas libérée. Le comportement attendu serait que le lecteur d'écran revienne en mode de navigation rapide et me laisse lire le reste de la page Web. Au lieu de cela, les touches fléchées contrôlent toujours mon choix dans la liste.
• Les scripts actuels ne permettent pas de savoir si les propositions sont affichées et combien sont-elles. Dans les plug-ins sélectionnés les plus accessibles que je connaisse, JAWS/NVDA annonce le nombre de résultats correspondant à la chaîne saisie dans la saisie de texte.
• Enfin, j'ai l'impression que JAWS ne comprend pas si la liste est regroupée ou étendue. Parfois, après avoir fait un choix avec ENTER et essayé de lire le reste de la page, JAWS lit encore les dernières propositions qui ont été affichées.

Bons points:

• La partie auto-complétée fonctionne bien. Si j'entre "fra", JAWS prononce "France", et je peux appuyer sur ENTER pour sélectionner.
• Les éléments sont lus correctement au fur et à mesure que je flèche dans la liste.

Je ne connais malheureusement pas grand chose en ce qui concerne ARIA, JavaScript et le web en général. Je vous suggère de vous assurer que le maximum de propriétés ARIA est correctement défini et mis à jour.

Veuillez trouver ci-dessous la démo et le code d'un plugin JQuery qui interagit parfaitement avec les lecteurs d'écran :
https://a11y.nicolas-hoffmann.net/autocomplete-list/

Je suis désolé de ne pas pouvoir aider plus.

N'hésitez pas à poster de nouvelles démos de votre travail. Je suis heureux de tester pour vous.