Chosen: Zugänglichkeitsprobleme mit Chosen

relevanter Artikel aus dieser Diskussion:

Viel zu viel braucht Arbeit. Anscheinend wurde die Barrierefreiheit nicht berücksichtigt
alles in diesem Widget, daher wäre viel WAI-ARIA- und JS-Arbeit erforderlich, um *
versuchen *, dies mit WCAG 2.0 konform zu machen.

Das größte Problem aus einem 30-Sekunden-Review mit FF6 / JAWS12 ist, dass die
Komponente wird als Eingabetyp=Text gefolgt von einer ungeordneten Liste dargestellt
aller Optionen (243 für Länder), an denen der Benutzer vorbei navigieren muss
ignorieren Sie sogar das Feld.

Das Suchtextfeld könnte für den Anfang ein Label verwenden, aber das ist leicht zu beheben.

Ein größeres Problem besteht darin, dass die generierten Listenelemente keine Anker enthalten. Können Benutzer von Bildschirmleseprogrammen Maßnahmen ergreifen, wenn sie wissen, wozu die Listenelemente dienen?

Dies ist ein sehr schönes Plug-In! Die Funktionalität gefällt mir sehr gut.
Wird es in Zukunft eine Entwicklung hin zu einer besseren Zugänglichkeit geben? WAI-ARIA hinzufügen, damit es WCAG 2.0 entspricht???

Ich habe gerade diesen Artikel auf der Website von thefilamentsgroups gelesen. Die ARIA-Rollen könnten sich für Chosen anbieten:
http://filamentgroup.com/lab/jquery_ipod_style_and_flyout_menus/

Beispiel: Auf die UL-Ergebnisse von Chosen würde role="menu" aria-activedescendant="active-menuitem" angewendet und die Ergebnisse <li> hätten role="menuitem".
Das Suchfeld im Dropdown-Menü "Ausgewählt" würde wahrscheinlich auch eine ARIA-Rolle benötigen?

@dotdreaming Sie weisen auf die richtige Dokumentation hin, aber die von Ihnen erwähnten Rollen sind nicht ganz korrekt.

Ich denke, die folgenden Rollen sollten verwendet werden:

• Kombinationsfeld .
• Möglichkeit

Ich fände es echt cool, wenn jemand wirklich in die WAI-ARIA-Dokumentation eintauchen und sie auf ausgewählte anwenden würde.

Wenn ich die Zeit finde, kann ich das selbst machen. Es sieht nicht so aus, als ob es sehr schwer wäre.

Gibt es irgendeine Bewegung, um ARIA in dieses Projekt einzubeziehen?

Auch wenn es mit Assistive Technology funktioniert, muss es auch getestet werden, um zu sehen, dass es auch mit reinen Tastaturbenutzern funktioniert.

Übrigens, dies ist nur eine Möglichkeit, die niedrig hängenden Früchte für Verbesserungen der Zugänglichkeit zu überprüfen, aber WAVE hat einige ziemlich grundlegende Dinge identifiziert, die bereinigt werden sollten -> http://wave.webaim.org/report?url=http%3A% 2F%2Fharvesthq.github.com%2Fchosen%2F&js=2

Wurden diese Probleme mit der Zugänglichkeit behoben? Ich verwende dies sehr gerne auf unserer Hauptuniversitätsseite, aber diese Probleme mit der Zugänglichkeit haben mich abgeschreckt

+1 - Wir haben Feedback von einem blinden Benutzer erhalten, dass die Dropdown-Listen "Ausgewählt" schwer zu verwenden sind und Schwierigkeiten bei der Auswahl von Optionen haben. Sie verwenden JAWS 14 als Screenreader.

Habe es nur mit einer Tastatur zur Navigation ausprobiert. Das Auswählen von Elementen funktioniert sehr gut und intuitiv (unten zum Öffnen der Liste für ein neues Element, oben/unten zum Navigieren in der Liste, esc zum Schließen der Liste, Enter zum Auswählen). Das Entfernen von Elementen aus der Mehrfachauswahl war unkompliziert (Rücktaste), aber das Löschen einer Einzelauswahl-Dropdown-Liste stellte sich vor größere Herausforderungen. Es sieht so aus, als ob ich, nachdem ich ein Element ausgewählt habe, nach unten drücken kann, um die Liste erneut zu öffnen, und dann nach oben navigieren, bis keine Option ausgewählt ist (ähnlich wie ein normales Dropdown-Menü, wenn Ihr erstes Element leer ist, wie in den Beispielen), aber ich bin kann die Eingabetaste nicht drücken, um die Null-Option auszuwählen. Eine Methode zum vollständigen Abwählen einer Option (oder zumindest einer leeren Standardoption) wäre sehr nützlich.

Ich bin mir auch nicht sicher, ob sich das lohnt, aber mir ist aufgefallen, dass die Daten immer noch im versteckten Auswahlsteuerelement gespeichert sind (ich gehe davon aus, dass sie so in das Formular übernommen werden). Es könnte sich lohnen, das Dropdown-Menü Chosen zu aktualisieren, wenn die Auswahl geändert wird - ich habe überlegt, ob dies die Kriterien 4.1.2 von WCAG erfüllen würde, da UAs programmgesteuert mit dem Select-Steuerelement interagieren können und wir Chosen als Fassade behandeln könnten oben aus Gründen der Zugänglichkeit.

Für den zweiten Teil müssen wir ein listz:updated auslösen, selbst wenn Sie den Wert des select-Steuerelements programmgesteuert ändern, um ausgewähltes zu aktualisieren.
Dies ist erforderlich, da Browser kein Ereignis auslösen, wenn der Wert programmgesteuert geändert wird, um Chosen darüber zu informieren (und wenn sie dies tun, müssten wir immer noch Endlosschleifen vermeiden, da wir ihn auch programmgesteuert ändern).

Ich werde mich heute mit dem Hinzufügen von Barrierefreiheit befassen. @marklagendijk Ich denke, was Sie erwähnt haben, ist der beste Weg, um

Dies kann hilfreich sein, aber auch nicht, aber wir müssen strenge Richtlinien zur Barrierefreiheit befolgen und mit Version 1.0.0 kam der Barrierefreiheitstester unseres Kunden mit den folgenden Kommentaren zurück:

1. das mit dem 'label' verbundene 'select' hat die Anzeige: keine; und so die
   'label' ist effektiv verwaist. Die 'div class="chosen-container-single"', die braucht
   sein Platz als Formularsteuerelement hat keinen programmgesteuerten zugänglichen Namen oder Label.

2.Es gibt keinen sichtbaren Fokus auf der Dropdown-Liste für Faux.

1. Es gibt keinen sichtbaren Fokus auf den Link in der Faux-Dropdown-Liste.

Ich verwende dies in Verbindung mit dem Drupal Chosen-Modul. Wir haben auch einen Blindtester, der feststellte, dass er, sobald er zur Eingabe kam, nicht wusste, dass er tippen konnte, noch die Ergebnisse zurückgegeben wurden, einschließlich "Keine Ergebnisse gefunden".

@marklagendijk
Alle Fortschritte zu diesem Thema. Ich überlege, das Problem erneut einzuführen, um Chosen zum Drupal-Kern hinzuzufügen, und dies ist der Hauptblocker.

Ein wirklich gutes Beispiel dafür habe ich hier gefunden:
http://cookiecrook.com/test/aria/multiselect/listbox.html
Hier ist das Javascript: http://cookiecrook.com/test/aria/multiselect/js/aria.js

Ich glaube, dass dies fast genau der ausgewählten Grundfunktionalität entspricht. Es sieht ziemlich einfach aus, wenn es mit der Listbox und den mehrfach auswählbaren Arieneigenschaften implementiert werden kann
http://www.w3.org/TR/wai-aria/roles#listbox
http://www.w3.org/TR/wai-aria/states_and_properties#aria -multiselectable

Ich würde selbst einen Patch machen, aber ich bin nicht so heiß auf js.

Meine oben verlinkte PR bietet eine Lösung mit einem viel einfacheren Ansatz, der sich auf die Prinzipien der progressiven Verbesserung konzentriert, anstatt den "tiefen Tauchgang" in die Erstellung eines vollständig zugänglichen Widgets aus der aktuellen Chosen-Codebasis zu unternehmen. Ich freue mich über jedes Feedback.

Warum sich auf ARIA konzentrieren, wenn es vom IE8 immer noch nicht richtig unterstützt wird? Leider ist dieser 5 Jahre alte Browser immer noch in der Liste der gängigen Browser. Dies bedeutet, dass eine von ARIA abhängige Implementierung fehlschlägt, wenn ein Zugriffsscan durchgeführt wird.

Warum nicht eine Fallback-Methode verwenden, die einfach alle ausgewählten Elemente deaktiviert und einem Benutzer die ursprüngliche Auswahl zur Verfügung stellt? Dies könnte durch das Hinzufügen eines (versteckten) Links erreicht werden, der einen kleinen Javascript-Code verwendet, der ausgewählte deaktiviert.

Ressource zur IE8 ARIA-Unterstützung: http://www.w3.org/TR/WCAG20-TECHS/wai-aria_notes.html

Sie könnten einfach die Browser-/Funktionserkennung durchführen und Chosen nicht verwenden, wenn IE8 verwendet wird.

@ Daniel15 Das wäre wahrscheinlich sogar eine einfachere Lösung. Danke für das Teilen deiner Gedanken. In meinem Beitrag wollte ich lediglich darauf hinweisen, dass die Implementierung von ARIA (vorerst) nicht bedeutet, dass es zugänglich und einsatzbereit für Anwendungen ist, die WCAG 2.0-kompatibel sein müssen.

Würde das gerne sehen. Screenreader und reine Tastaturbenutzer benötigen wirklich Zugriff auf diese Felder. Der IE8 interessiert mich nicht so sehr, aber zumindest eine Lösung für moderne Browser wäre akzeptabel. Ich mag die IE8-Fallback-Idee sehr. Es sieht so aus, als ob es zwei gute PRs gibt – ich würde gerne sehen, dass einer von ihnen zusammengeführt wird.

ein dickes +1 dazu bitte

+1 (+) Wir müssen dies in Chosen haben. Es ist ein Problem

aria-label (Eigenschaft)

Definiert einen Zeichenfolgenwert, der das aktuelle Element bezeichnet. Siehe auch aria-labelledby.

Der Zweck von aria-label ist der gleiche wie der von aria-labelledby. Es liefert dem Benutzer einen erkennbaren Namen des Objekts. Die gebräuchlichste Accessibility-API-Zuordnung für ein Label ist die barrierefreie name-Eigenschaft.

Wenn der Beschriftungstext auf dem Bildschirm sichtbar ist, SOLLTEN Autoren aria-labelledby und NICHT aria-label verwenden. Es kann Fälle geben, in denen der Name eines Elements nicht programmgesteuert aus dem Inhalt des Elements bestimmt werden kann, und es gibt Fälle, in denen die Bereitstellung einer sichtbaren Bezeichnung nicht die gewünschte Benutzererfahrung ist. Die meisten Hostsprachen stellen ein Attribut bereit, das verwendet werden könnte, um das Element zu benennen (zB das title-Attribut in HTML [HTML]), jedoch kann dies einen Browser-Tooltip darstellen. In den Fällen, in denen ein sichtbares Label oder ein sichtbarer Tooltip unerwünscht ist, KÖNNEN Autoren den zugänglichen Namen des Elements mit aria-label festlegen. Benutzerprogramme geben aria-labelledby Vorrang vor aria-label, wenn sie die barrierefreie name-Eigenschaft berechnen.

@Natshah Können Sie mit der Änderung einen Pull-Request durchführen?

@Natshah , können Sie https://github.com/harvesthq/chosen/pull/2047 überprüfen, um zu sehen, ob es richtig implementiert wird?

Hallo,

Ich habe dies für meinen Fall unter diesem Link behoben
https://www.drupal.org/node/2384865

Danke.

Lohnend :)

Ja. Das sollte so etwas wie im folgenden Code sein. .

      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>');
      }

Aber wir können diesen Code verwenden:

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

Danke.

Lohnend :)

Gibt es hierzu Neuigkeiten? Wir haben vor kurzem ausgewählte Felder implementiert und hatten Feedback von Benutzern, die die Hilfstechnologie "Jaws" verwenden, dass sie die ausgewählten Felder überhaupt nicht verwenden können.

Scheint ein wichtiges Thema zu sein, das es zu untersuchen gilt. Gab es an dieser Front Bewegung?

Mir ist nichts bekannt, leider ist es angesichts der massiven Kombinationen von unterstützenden Technologien mit Browsern und Betriebssystemen sehr schwer, Probleme zu replizieren... Normalerweise sollte es in den meisten Fällen funktionieren, solange Sie die Tastaturnavigation können + Sie die korrekte ARIA-Implementierung haben.

Zur schnellen Lösung habe ich dafür gesorgt, dass Screenreader zumindest das ursprüngliche Auswahlfeld verwenden können. Anstatt das select-Element auszublenden, füge ich dazu eine screenreaders-only Klasse und aria-hidden:true zum generierten ausgewählten Container hinzu.

Also, in chosen.jquery.js Zeilen 599 to 605 sieht so aus:

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

Und Zeile 616 sieht so aus:

      // 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);

Es ist keine perfekte Lösung, da sowohl die versteckte Auswahl als auch das Widget über die Tastatur fokussiert werden können, aber es ist viel besser als ein unzugängliches Widget.

Das hat bei mir funktioniert.
Ich habe alle oben genannten Ratschläge befolgt und die folgende Zeile geändert:

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

zu:

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

Danke

Versuchen Sie, ob es funktioniert. Die Struktur sollte so sein. :)

Ich habe versucht , einige ARIA-Elemente hinzuzufügen, die auf der Arbeit von

Ich habe hier eine Filiale zur Verfügung , die Folgendes tut:

ARIA-Etiketten und andere hilfreiche Attribute

• Fügt die folgenden Arienelemente zum Sucheingabefeld hinzu
  
  
  
  • Rolle="Kombibox"
  
  
  • Wird verwendet, um anzuzeigen, dass Benutzer eine Option eingeben oder einer Liste neue Elemente hinzufügen können
  
  
  • aria-haspopup (implizit bei Verwendung der Combobox-Rolle)
  
  
  • Wird verwendet, um anzuzeigen, dass dieses Feld ein zugehöriges Menü hat
  
  
  • Arie-erweitert
  
  
  • Erforderlich bei Verwendung der Combobox, zeigt an, dass die Ergebnisliste sichtbar oder ausgeblendet ist
  
  
  • Der Status muss dynamisch aktualisiert werden, wenn das ausgewählte Feld aktiviert/deaktiviert wird
  
  
  • aria-activedescendant="id_of_highlighted_option"
  
  
  • Wird verwendet, um anzuzeigen, welche Optionen der aktuell ausgewählte Wert ist
  
  
  • Dies muss aktualisiert werden, wenn eine neue Option ausgewählt wird
  
  
  • aria-owns="id_of_list_of_options"
  
  
  • Gibt die Liste der Auswahlmöglichkeiten an, auf die sich dieses Suchfeld bezieht
  
  
  • aria-autocomplete="Liste"
  
  
  • "Wenn ein Autor den Wert von aria-autocomplete einer Combobox auf 'list' setzt, MÜSSEN Benutzeragenten Änderungen am aria-activedescendant-Attribut in der Combobox offenlegen, während die Combobox fokussiert bleibt. Wenn eine Änderung am aria-activedescendant-Attribut erfolgt, während die Combobox fokussiert ist, SOLLTEN Assistive Technologien den Benutzer über diese Änderung informieren, indem sie beispielsweise die Textalternative des neuen aktiven Nachkommenelements sprechen. Autoren SOLLTEN das Combobox-Textfeld mit ihrer Listbox mit aria-owns zuordnen."
  
  
  • aria-labeledby="id_of_field_label"
  
  
  • Dies ist die ID des ausgewählten Formularetikettenelements, das ersetzt wird
  
  
• Fügt der Liste der Optionen die folgenden Attribute hinzu
  
  
  
  • Ich würde
  
  
  • Eine einfache ID basierend auf der Formularfeld-ID, auf die das aria-owns-Attribut im Sucheingabefeld abzielen soll
  
  
  • Rolle="Listenfeld"
  
  
  • "Ein Widget, mit dem der Benutzer ein oder mehrere Elemente aus einer Auswahlliste auswählen kann."
  
  
• Fügt jeder einzelnen Option in der Liste der Optionen die folgenden Attribute hinzu
  
  
  
  • Ich würde
  
  
  • Eine einfache ID basierend auf dem Index der Option in der Liste und der Formularfeld-ID, die vom aria-activedescendant verwendet werden soll, die das aktuell ausgewählte Element angibt
  
  
  • Rolle="Option"
  
  
  • Ein auswählbares Element in einer Auswahlliste.
  
  
  • Arie-beschäftigt
  
  
  • Der Grund dafür ist, dass Chosen, wenn es für ein Feld initialisiert wird, die Optionsliste _nicht_ baut, bis das Feld zum ersten Mal aktiviert wird.
  
  
  • Dies ist ein Problem bei der Assistenztechnologie sowie bei Scannern, die nach Zugänglichkeitsproblemen suchen. Da die Suchbox (role="combobox") jetzt delcaring ist, besitzt sie eine Listbox (aria-owns="id_of_list_of_options"), die Listbox (unsere Ergebnisliste) _muss_ Optionen enthalten ODER als beschäftigt deklariert werden, um den Anforderungen zu entsprechen die spez.
    
    
    
    
    
    • Ich bin mir nicht einmal 100% sicher, ob das der richtige Schritt ist. Es verhindert sicherlich, dass die Felder von Scannern markiert werden, aber diese sind nicht vollständig belegt, wir haben nur die Optionen noch nicht entwickelt.
    
    
    
  
  
  • Ich hoffe, jemand mit mehr A11Y-Erfahrung kann dazu Stellung nehmen.
  
  
  • Ich habe auch einen radikaleren Ansatz in Betracht gezogen, bei dem die Ergebnisliste erstellt wird, wenn ein Feld zum ersten Mal aktiviert wird, aber das beinhaltet das Hinzufügen eines neuen Auslösers zu Chosen.
    
    
    
    
    
    • Dieser Trigger war im Wesentlichen ein Durchgang zur Methode winnow_results, die die Suchergebnisse (noch versteckt) erstellte, aber Scanner glücklich machte.
    
    
    
  
  

Verwaltungsstaat

• Verwalten des aria-expanded-Attributs
  
  
  
  • Um anzugeben, wann die Suchergebnisse für die Assistive Technologie relevant sein sollten, müssen wir das aria-expanded-Attribut umschalten, wenn Felder aktiviert/deaktiviert werden.
  
  
  • Der einfachste Weg, dies zu tun (AFAIK), besteht darin, das Attribut während der Methoden close_field und activate_field anzupassen.
  
  
  • Ein einfacher Wechsel von true zu false oder false zu true in jeder dieser Methoden reicht aus, um den Status aktuell zu halten
  
  

Ich werde diese Version für mehrere unserer Projekte verwenden und werde meinen Zweig mit Änderungen aktualisieren, sobald wir einen detaillierteren Blick auf unsere Projekte aus einer A11Y-Ansicht erhalten.

Danke an alle, die bis hierher gelesen haben, ich weiß, es ist viel und bitte, wenn Sie Feedback haben, lassen Sie es mich wissen! Ich möchte das so weit wie möglich vorantreiben.

@cooperfellows bitte öffnen Sie einen Pull Request mit Ihren Änderungen

@stof Fertig, aber wie gesagt, ich bin kein A11Y-Experte und plane weitere Tests. Ich wollte hier nur meinen ersten Stallpass mitteilen.

Gibt es dazu ein "offizielles" Update? Wurden aufgrund der Bemühungen von

Der Grund, warum ich frage, ist, dass immer mehr Jaws-Benutzer das Widget als unbrauchbar melden, wodurch das Formular, das sie betrachten, effektiv unbrauchbar wird.

Wir können replizieren, also gerne helfen / Beispiele teilen, wenn das hilft?

Die Pull-Anfrage wurde gestellt (es gab einige kleinere Probleme, die im Nachhinein behoben wurden), aber es ist noch nichts passiert. Der Branch, den ich gerade in der Produktion verwende, ist hier:

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

Ich würde mich jedoch über ein anderes Feedback freuen. Ich habe keine Jaws, daher verlasse ich mich auf Audits von verschiedenen Online-Tools.

Dieser Zweig ist also im Grunde die aktuelle Produktion plus Ihre Änderungen oder eine frühere Version mit den letzten Änderungen, die noch nicht zusammengeführt wurden?

(Danke übrigens)

Ja, das stimmt @wcndave. Obwohl die PR wirklich andere Augen für die Überprüfung gebrauchen könnte.

@cooperfellows Ich

Gibt es ein Update zu Ihrem Pull-Request?

Dumme Frage - hast du eine kompilierte JavaScript-Version, die ich herunterladen kann?
Oder muss ich Coffeescript installieren und selbst kompilieren?

@KITSKevinBonett Danke für die Hilfe!

Angehängt ist eine Zip-Datei der Version vom Typ jquery und proto, sowohl komprimiert als auch unkomprimiert.

kompiliert-a11y-chosen-jquery-proto.zip

@cooperfellows Das ging schnell. Ich werde unser Projekt erweitern, einige Tests durchführen und Sie wissen lassen ...

@KITSKevinBonett Ya, ich

Hallo @cooperfellows - Ich habe Ihre Implementierung überprüft - in der Tat sehr gut.

Es gibt einige Probleme, die aufgrund von Bildschirmlese-/Browser-Inkompatibilitäten möglicherweise nicht (einfach) gelöst werden können.

Meine Erkenntnisse habe ich im Anhang dokumentiert. Ich habe 1 oder 2 kleinere Empfehlungen gegeben, von denen ich hoffe, dass Sie sie nützlich finden.

_AKTUALISIEREN_

1. Einige meiner Kommentare erwähnten Funktionen, die für unsere Implementierung lokal sind - ich habe diese entfernt.
2. Problem mit der Eingabe in "Combobox" und Drücken der EINGABETASTE - unser Formularsenden wird nicht aktiviert - auch dies ist ein lokales Implementierungsproblem.
3. Die ZIP unten wurde aktualisiert, um (1) und (2) zu entfernen.

aria-chosen-plugin.zip

Hallo @cooperfellows - war mein Audit sinnvoll?

Hallo @KITSKevinBonett Ich war eine Woche im Urlaub. Ich werde mir das mal anschauen, sobald ich mit meinen anderen Arbeiten beschäftigt bin. Danke für das Feedback, ich bin sicher, es ist hilfreich.

@KITSKevinBonett Danke für die Prüfung, das scheint ziemlich gründlich zu sein. Ich habe meine Gedanken basierend auf den Abschnitten des Audits aufgeschlüsselt, wie Sie sie dargelegt haben.

Vom Plugin generiertes HTML-Markup

• Gibt es hier Feedback? Oder zeigen Sie nur, was generiert wird?

Nur-Tastatur-Verhalten

• "Wenn die Option jedoch ausgewählt wurde, geht der Tastaturfokus beim erneuten Tabulator verloren."
  
  
  
  • Ich denke, dies könnte gelöst werden, indem das aria-hidden- Attribut ein- und ausgeschaltet wird, wenn dieses Element sichtbar / ausgeblendet wird?
  
  
  • Ich werde diesen Ansatz prüfen.
  
  
• "CSS-deaktivierte Probleme"
  
  
  
  • Standardauswahl ist sichtbar
  
  
  • Ich kann das nicht reproduzieren, können Sie mir einen Screenshot oder einen Screencast geben oder so?
  
  
  • Kein sichtbarer Hinweis beim Hervorheben von Ergebnissen mit der Tastatur.
  
  
  • Wir könnten den Text des aktuell markierten Elements in ein <em> Tag einschließen, das kursiv gedruckt wird (zumindest in Chrome).
    
    
    
    
    
    • Das potenzielle Problem hierbei ist, dass die Suche auch <em> , um Textübereinstimmungen anzuzeigen, daher würde ich mir Sorgen machen, dass diese möglicherweise miteinander in Konflikt geraten.
    
    
    
  
  

Bildschirmlesegeräte

• Ich habe keinen Zugriff auf JAWS, daher kann ich hier nicht allzu viel tun. Ich werde eine Testversion starten, wenn ich mehr Zeit habe, um zu sehen, was ich finden kann.
• Screenreader sind der Bereich, bei dem ich mich über etwas mehr Hilfe sehr freuen würde, also vielen Dank für die detaillierte Aufschlüsselung.

Arie Gedanken

• Ich kann das haspopup-Attribut entfernen, wie Sie bemerkt haben, es ist überflüssig.
• Der Grund, warum ich aria-busy hinzugefügt habe, ist, dass Chosen standardmäßig keine Listenelemente in den versteckten Divs generiert, bis der Fokus platziert wird.
  
  
  
  • Dies bedeutet, dass das Element role="listbox" standardmäßig keine Optionen hat, was beim Scannen mit Tools zu Problemen führte. Durch Hinzufügen des aria-busy-Elements am Anfang wird es von diesen Tools ignoriert.
  
  
  • Der Grund für das Problem ist, dass ein Listbox-Element ein Optionselement ( Quelle ) _besitzen muss_
  
  
  • Es wird entfernt, wenn die Liste zum ersten Mal ausgefüllt wird, daher schien es mir eine No-Harm No-Foul-Situation zu sein.
  
  
• Das Hinzufügen von aria-selected scheint ein offensichtlicher Schritt zu sein, ich kann nicht glauben, dass ich das übersehen habe. Danke, dass du es erwischt hast.
  *Schlussgedanken*
  Haben Sie den HTML-Code für dieses Audit selbst geschrieben oder hat ein Tool dies für Sie erstellt? Es ist sehr hilfreich, also nochmals vielen Dank.

@cooperfellows - Antworten auf Ihre Fragen:

HTML-Markup

• Zeigt nur an, was in jeder Phase des Plugin-Verhaltens generiert wird.

Tastaturverhalten

• Der "verlorene Fokus" ist nur in Firefox vorhanden. Sie können tabindex="-1" hinzufügen, um den Fokus zu verhindern, und dann wieder entfernen. Dann bräuchtest du ARIA nicht.

CSS deaktiviert

• Grundsätzlich ist das ursprüngliche SELECT auf der Seite sichtbar und mit UP | . nutzbar ABWÄRTS-Pfeile, weil das standardmäßige Browserverhalten die verschiedenen Optionen anzeigt, während Sie durch sie navigieren.
• Der vom Plugin gerenderte HTML-Code ist ebenfalls sichtbar, aber die Dropdown-Liste zeigt nicht an, welche "Option" hervorgehoben ist.
• Sie haben vorgeschlagen, ein EM zu verwenden. Verwenden Sie stattdessen STRONG - es hat mehr semantische Bedeutung als EM in HTML5. Siehe http://html5doctor.com/ib-em-strong-element/
• Aber ich glaube nicht, dass dies ein großes Problem ist, da Benutzer SELECT weiterhin verwenden können.
• Siehe Screenshot

Screenreader

• Dies ist schwierig, da die Ergebnisse je nach verwendeter Browser- und Bildschirmlesekombination und Version variieren.
• Was ich sagen würde, ist, dass Ihre Zugänglichkeitsaktualisierungen für das Plugin in Bezug auf ARIA-Rollen / -Zustände / -Eigenschaften an W3C / WAI-Empfehlungen ausgerichtet sind. Das sind also gute Nachrichten. :)
• Es liegt an den Browser- und Screenreader-Herstellern, sicherzustellen, dass ihre Software diese einhält.

ARIE

• Ihre Erklärung für "aria-busy" macht Sinn. Selbst wenn es veraltet war, wird es keine Probleme verursachen.
• HTML prüfen. Handgemacht. Ich habe für das Unternehmen, für das ich arbeite, eine UI-Komponentenbibliothek / einen Living Style Guide erstellt, also habe ich nur Komponenten von dort verwendet. Hat gar nicht lange gedauert. Der schwierigste Teil war, sich die gesamte Ausgabe des Bildschirmleseprogramms noch einmal anzuhören, um sicherzustellen, dass ich alles richtig erfasst hatte.

Ich hoffe, das hilft alles bei Ihrer Pull-Anfrage. Sie haben mit dem A11Y großartige Arbeit geleistet. :)

Hallo,

Ich bin blind. Ich habe die Arbeit von @cooperfellows mit JAWS getestet. Es funktioniert perfekt. Die ausgewählte Option wird gesprochen, während ich durch die Optionen navigiere.

Gibt es Neuigkeiten zum Zusammenführen in Master?

In meiner täglichen Arbeit verwende ich MISP (Malware Information Sharing Platform - https://github.com/MISP/MISP), deren Entwickler sich kürzlich dazu entschieden haben, "chosen" für Autovervollständigungs-Comboboxen zu verwenden. Es ist ein Albtraum für mich geworden.

Vielen Dank im Voraus für Ihre Hilfe.

Nach einigen Tests kann ich bestätigen, dass die oben gepostete kompilierte Version (.zip-Archiv) (am 1. Juli 2016) funktioniert.

Wenn ich jedoch den Zweig von oder den Zweig von @cooperfellows klone und dann mit Harvesthq/master zusammenführe, werden die Menüoptionen von JAWS richtig gesprochen, aber die EINGABETASTE sendet das Formular nicht.

Hallo @obert01 , du dir das mit JAWS

Dieser Branch ist im Vergleich zum aktuellen Harvesthq/Master-Branch weit veraltet. Ich werde wahrscheinlich die Änderungen überprüfen

Ich werde versuchen, irgendwann vor Ende des Monats dazu zu kommen, ich bin gerade bei der Arbeit ziemlich gestärkt.

Ich würde gerne wieder einen der Mitwirkenden darauf aufmerksam machen, sobald es aktualisiert ist, also werde ich @stof (der sich den ersten Rückzug im Jahr 2016 angesehen hat)

Vielen Dank.

Zu Ihrer Information kann ich mit allen Kombinationen von JAWS- und NVDA-Screenreadern mit folgendem Browser testen: Internet Explorer 11, Google Chrome, Firefox ESR, Firefox Standard, Microsoft Edge.

Gibt es diesbezüglich Fortschritte?

Es tut mir leid, darauf zu bestehen, aber meine tägliche Arbeit leidet unter dieser mangelnden Zugänglichkeit.

Darüber hinaus würde das Hinzufügen von Barrierefreiheitsunterstützung die Verwendung von Chosen auf Websites des öffentlichen Sektors / der Verwaltung ermöglichen, da die Regulierung in immer mehr Ländern in diese Richtung geht.

Danke schön

Hallo,
Wir haben eine Anwendung, die ausgewählt wurde, und jetzt müssen wir die Barrierefreiheit unterstützen, aber ich kann sehen, dass dies noch nicht zusammengeführt wurde. Es wird sehr hilfreich sein, wenn @cooperfellows dies abschließen und bitte zusammenführen kann.

Hallo @obert01 und @csmuthukuda ,

Ich habe gerade Updates gemacht, um meine PR mit der neuesten Version von Chosen auf den neuesten Stand zu bringen. Schauen Sie bitte hier:
https://github.com/harvesthq/chosen/pull/2596

Sie können eine Kopie meines geforkten Repositorys erhalten und auf Ihrer Seite testen. Ich würde mich über ein Feedback aus dem wirklichen Leben freuen.

Es hat alle TravisCI-Prüfungen bestanden, aber ich glaube nicht, dass sie irgendwelche A11Y-Probleme abdecken. Lass mich wissen was du denkst.

Hallo @cooperfellows ,
Vielen Dank für Ihren Einsatz, um dies am Leben zu erhalten. Ich werde das testen und euch das Feedback dazu geben. Ich hoffe wirklich, dass die Besitzer erwägen, dies mit dem Master zusammenzuführen. Dies ist jetzt eine zwingende Voraussetzung.

Danke @csmuthukuda Ich würde mich

@pfiller @stof @tjschuck @koenpunt , kann ich etwas tun, um das zu untersuchen? Es ist wirklich ein fehlendes Stück für ein ansonsten unglaublich tolles System.

Hallo @cooperfellows ,

Ich habe Ihre großartige Arbeit mit den meisten aktuellen Webbrowsern und den JAWS- und NVDA-Screenreadern getestet. Danke schön !

Das Durchblättern der Optionen mit der Tastatur funktioniert gut: Sprach- und Braille-Feedback sind perfekt, sodass alle ARIA-Attribute gut definiert sind. Wenn ich jedoch ENTER drücke, um eine Option auszuwählen, passiert nichts. Ich habe nicht genug Erfahrung mit JavaScript, um festzustellen, ob das Problem von Chosen stammt oder in der Anwendung vorhanden ist, die es verwendet.

Versuchen Sie zum Reproduzieren eine Option in einem ausgewählten Kombinationsfeld auszuwählen, das nur die Tastatur verwendet: TAB, um das Kombinationsfeld zu fokussieren, Pfeiltasten, um die Liste zu durchsuchen, EINGABETASTE, um auszuwählen.

Noch ein Mal vielen Dank.

Danke für diese Informationen @obert01. Ich werde mal nachschauen, was ich finden kann.

@ obert01 Können Sie versuchen, diese JS-Geige zu verwenden, um zu bestätigen, dass sie funktioniert / nicht funktioniert? Diese Geige lädt die kompilierte jQuery-Version meines neuesten Commits.

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

Ich kann in dieser Dropdown-Liste mit meiner Tastatur (Chrome Latest) navigieren, führe jedoch KEINEN Screenreader aus.

Lass mich wissen was du denkst.

Hallo @cooperfellows ,

Kein Problem mit Ihrer JS Fiddle. Daher vermute ich, dass das Problem auf die Art und Weise zurückzuführen ist, wie Chosen in MISP verwendet wird (https://www.misp-project.org/).

Ich werde dies mit dem MISP-Projektteam überprüfen.

Danke

Danke @obert01. Bitte lassen Sie mich wissen, was Sie herausgefunden haben. Es könnte auf eine Inkompatibilität mit einem bestimmten Setup von Chosen hinweisen. Wenn ich also eine Möglichkeit habe, zu sehen, wie MISP es nutzt, kann ich versuchen, mir deren Implementierung anzusehen.

Wird gewählt irgendwo öffentlich verwendet?

@cooperfellows können Sie mir bitte einen neuen Build mit den neuesten Änderungen geben, ich weiß nicht, wie ich ihn bauen soll.

@obert01 @cooperfellows Ich habe gerade die Fiddle mit NVDA ausprobiert, es scheint, dass die Tastaturnavigation perfekt funktioniert (einschließlich der Auswahl mit der EINGABETASTE). Wenn ich jedoch mit den Pfeiltasten nach oben und unten navigiere, liest der Screenreader "________nicht ausgewählt", dh "Bermuda nicht ausgewählt". Ist das das erwartete Verhalten?

Ich habe das gleiche Problem wie @woenlee. Es ist nicht so schädlich. Aber vielleicht sollte überprüft werden, wie das Attribut "ausgewählt" für das ausgewählte Element festgelegt wird.

Was ist das erwartete Verhalten, wenn Sie ein Listenelement "betreten" und "verlassen"? Wann
Sie navigieren nach unten auf ein neues Element, sollte es das neu ausgewählte vorlesen
Artikel? Gibt es auch bekannt, was NICHT mehr ausgewählt wird? @obert01 @woenlee

Am So., 25. August 2019 um 12:18 Uhr Olivier BERT [email protected]
schrieb:

Ich habe das gleiche Problem wie @woenlee https://github.com/woenlee . Es ist nicht
so schädlich. Aber vielleicht ist die Art und Weise, wie das Attribut "ausgewählt" auf dem
Das ausgewählte Element sollte überprüft werden.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/harvesthq/chosen/issues/264?email_source=notifications&email_token=ABT3ZTIESGLX6IYW4BF2QCLQGKWDVA5CNFSM4AATGGB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVZ87D2
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ABT3ZTMH2KUYYE7HNO2UGH3QGKWDVANCNFSM4AATGGBQ
.

--
~Cooper

@cooperfellows Nachdem ich einige Axt-Zugänglichkeitstests durchgeführt habe, scheine ich einen Fehler in Ihrem PR gefunden zu haben, der erklärt, warum dies der

<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>

Nach dem Geben

Das Bezahlen von Kunden von Harvest hier und das Testen, um intern zugänglich zu sein, stießen darauf. Zugänglichkeit ist ein Muss, und wir werden Harvest aufgeben, wenn dies nicht angegangen wird, wenn ein Betreuer von Harvest nicht zumindest bald Unterstützung dafür zeigt.

@ obert01 Können Sie versuchen, diese JS-Geige zu verwenden, um zu bestätigen, dass sie funktioniert / nicht funktioniert? Diese Geige lädt die kompilierte jQuery-Version meines neuesten Commits.

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

Ich kann in dieser Dropdown-Liste mit meiner Tastatur (Chrome Latest) navigieren, führe jedoch KEINEN Screenreader aus.

Lass mich wissen was du denkst.

@cooperfellows
Ich habe diese JS-Geige mit JAWS 2019 getestet und beim Navigieren durch die Optionen mit den Auf- und Ab-Pfeiltasten etwas anderes erlebt.
Auf Google Chrome 71.0.3578.98:
JAWS würde den aktuell hervorgehobenen Wert nicht lesen, es sei denn, die Liste hat etwas gescrollt/gerendert. dh Wenn die Liste angezeigt wird

<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 Optionen, JAWS liest die hervorgehobene Option nicht, wenn Sie nach unten drücken, bis Sie zur 10. Option bei . gelangenAntigua und Barbuda . Die Box führt einen kleinen automatischen Bildlauf durch, um Antigua und Barbuda hervorzuheben und dann die Option zu lesen.

Auf IE 11.0.9600.19463: Das Navigieren mit den Pfeiltasten scheint die aktuell hervorgehobene Option korrekt nach oben und unten zu lesen. Erfordert keine Art von Rendering.

Würde gerne wissen ob das noch jemand erlebt hat. @obert01 @woenlee

Hallo und danke für deine Arbeit.

Leider funktioniert dies nicht richtig. Es ist äußerst schwer zu beschreiben, da sich das Verhalten in der Funktion des verwendeten Browsers oder Screenreaders ändert.

Ich denke, einige Arieneigenschaften sind nicht vorhanden oder werden nicht aktualisiert. Hier die allgemeinen Probleme, auf die ich stoße:

• Scroll-Problem: Wenn ich mit dem Pfeil nach unten das Ende der sichtbaren Liste von Elementen erreiche, muss ich zweimal auf den Pfeil nach unten drücken, um das nächste Element zu fokussieren.
• Wenn ich ENTER drücke, um ein Element auszuwählen, wird der Fokus nicht freigegeben. Das erwartete Verhalten wäre, dass der Bildschirmleser in den Schnellnavigationsmodus zurückkehrt und mich den Rest der Webseite lesen lässt. Stattdessen steuern die Pfeiltasten immer noch meine Auswahl in der Liste.
• Die aktuellen Skripte erlauben nicht zu wissen, ob und wie viele Vorschläge angezeigt werden. In den meisten zugänglichen Select-Plugins, die ich kenne, gibt JAWS/NVDA an, wie viele Ergebnisse mit der in der Texteingabe eingegebenen Zeichenfolge übereinstimmen.
• Schließlich habe ich den Eindruck, dass JAWS nicht versteht, ob die Liste kollabiert oder erweitert wird. Manchmal, nachdem Sie eine Auswahl mit ENTER getroffen und versucht haben, den Rest der Seite zu lesen, liest JAWS immer noch die zuletzt angezeigten Vorschläge.

Gute Argumente:

• Die Autovervollständigung funktioniert gut. Wenn ich "fra" eingebe, spricht JAWS "Frankreich" aus und ich kann zur Auswahl ENTER drücken.
• Die Elemente werden richtig gelesen, wenn ich den Pfeil in der Liste zeige.

Leider kenne ich mich mit ARIA, JavaScript und Web im Allgemeinen nicht aus. Ich schlage vor, dass Sie sicherstellen, dass das Maximum der ARIA-Eigenschaften richtig eingestellt und aktualisiert ist.

Nachfolgend finden Sie die Demo und den Code eines JQuery-Plugins, das perfekt mit Screenreadern interagiert:
https://a11y.nicolas-hoffmann.net/autocomplete-list/

Es tut mir leid, dass ich nicht mehr helfen kann.

Zögern Sie nicht, neue Demos Ihrer Arbeit zu veröffentlichen. Gerne teste ich für Sie.