Chosen: Problemas de accesibilidad con Chosen

pieza relevante de esa discusión:

Demasiado necesita trabajo. Parece que la accesibilidad no se ha considerado en
todo en este widget, por lo que se necesitaría mucho trabajo WAI-ARIA y JS para *
Intente * hacer que esto se ajuste a WCAG 2.0.

El mayor problema, de una revisión de 30 segundos con FF6 / JAWS12 es que el
El componente se representa como un tipo de entrada = texto seguido de una lista desordenada
de todas las opciones (243 para los países) que el usuario necesita para navegar más allá de
incluso ignorar el campo.

El campo de texto de búsqueda podría usar una etiqueta, para empezar, pero eso es fácil de arreglar.

Un problema mayor es que los elementos de la lista generada no tienen anclajes ... ¿pueden los usuarios de lectores de pantalla tomar medidas si saben para qué sirven los elementos de la lista?

¡Este es un complemento muy bueno! Me gusta mucho la funcionalidad.
¿Habrá algún desarrollo futuro hacia una mejor accesibilidad? ¿Agregar WAI-ARIA para que se ajuste a WCAG 2.0 ???

Acabo de leer este artículo en el sitio web de thefilamentsgroups. Los roles de ARIA podrían prestarse a Chosen:
http://filamentgroup.com/lab/jquery_ipod_style_and_flyout_menus/

Por ejemplo: los resultados elegidos UL tendrían role = "menu" aria-activedescendant = "active-menuitem" aplicado a ellos y los resultados <li> tendrían role = "menuitem".
¿El cuadro de búsqueda en el menú desplegable Elegido probablemente también necesitaría algún tipo de rol ARIA?

@dotdreaming señala la documentación correcta, pero los roles que menciona no son del todo correctos.

Creo que deberían usarse los siguientes roles:

• combobox .
• opción

Creo que sería genial si alguien realmente se sumergiera en la documentación WAI-ARIA y la aplicara a los elegidos.

Si puedo encontrar el tiempo, puedo hacerlo yo mismo. No parece que sea muy difícil de hacer.

¿Algún movimiento para que ARIA participe en este proyecto?

Incluso si funciona con tecnología de asistencia, también debe probarse para ver que también funciona con usuarios que solo utilizan teclado.

Por cierto, esta es solo una forma de comprobar las mejoras de accesibilidad que están al alcance de la mano, pero WAVE identificó algunas cosas bastante básicas que deberían limpiarse -> http://wave.webaim.org/report?url=http%3A% 2F% 2Fharvesthq.github.com% 2Felegido% 2F & js = 2

¿Se ha abordado alguno de estos problemas de accesibilidad? Realmente me gusta usar esto en nuestro sitio principal de la universidad, pero estos problemas de accesibilidad me desaniman

+1: hemos recibido comentarios de un usuario ciego de que las listas desplegables de Elegidos son difíciles de usar y tienen dificultades para seleccionar opciones. Están usando JAWS 14 como su lector de pantalla.

Probado solo con un teclado solo para la navegación. La selección de elementos funciona muy bien e intuitivamente (abajo para abrir la lista para un nuevo elemento, arriba / abajo para navegar por la lista, esc para cerrar la lista, ingresar para seleccionar). Eliminar elementos de la selección múltiple fue sencillo (retroceso), sin embargo, borrar un menú desplegable de selección única se presentó con más desafíos. Parece que, habiendo seleccionado un elemento, puedo presionar hacia abajo para abrir la lista nuevamente y luego navegar hacia arriba hasta que no se seleccione ninguna opción (muy parecido a un menú desplegable normal si su primer elemento está en blanco como los ejemplos), pero estoy incapaz de presionar Enter para seleccionar la opción nula. Algún método para anular la selección de una opción por completo (o al menos una opción predeterminada en blanco) sería muy útil.

Tampoco estoy seguro de si esto vale la pena, pero noté que los datos aún se almacenan en el control de selección oculto (supongo que así es como se pasan al formulario). También podría valer la pena actualizar el menú desplegable Elegido cuando se cambia la selección; estaba debatiendo si esto satisfaría el criterio 4.1.2 de WCAG, ya que los UA pueden interactuar con el control de selección de manera programática y podríamos tratar Elegido como una fachada en parte superior de la misma a los efectos de la accesibilidad.

para la segunda parte, estamos solicitando activar un listz:updated incluso cuando cambie el valor del control de selección mediante programación para actualizar elegido.
Esto es necesario porque los navegadores no activan un evento cuando el valor se cambia programáticamente para que Chosen lo sepa (y si lo estuvieran haciendo, todavía tendríamos que evitar bucles infinitos ya que también lo estamos cambiando programáticamente)

Voy a considerar la posibilidad de agregar accesibilidad hoy. @marklagendijk Creo que lo que mencionaste es la mejor manera de ir a un

Esto puede ser útil, puede que no, pero tenemos pautas estrictas de accesibilidad a seguir y con la versión 1.0.0, el probador de accesibilidad de nuestro cliente regresó con los siguientes comentarios:

1. el 'seleccionar' asociado con la 'etiqueta' tiene pantalla: ninguno; y entonces el
   "etiqueta" queda efectivamente huérfana. El 'div class = "selected-container-single"' que toma
   su lugar como control de formulario no tiene un nombre o etiqueta accesible mediante programación.

2. No hay un foco visible en el menú desplegable falso.

1. No hay un foco visible en el enlace dentro del menú desplegable falso.

Estoy usando esto junto con el módulo Drupal Chosen. También tenemos un probador ciego que notó que una vez que llegó a la entrada no se dio cuenta de que podía escribir, ni los resultados devueltos, incluido "No se encontraron resultados".

@marklagendijk
Cualquier progreso en este tema. Estoy buscando reintroducir el problema para agregar Chosen al núcleo de Drupal y este es el bloqueador principal.

Encontré un muy buen ejemplo de cómo se puede hacer esto aquí:
http://cookiecrook.com/test/aria/multiselect/listbox.html
Aquí está el javascript: http://cookiecrook.com/test/aria/multiselect/js/aria.js

Creo que esto se asigna casi exactamente a la funcionalidad básica elegida. Parece bastante simple de implementar usando el cuadro de lista y las propiedades de aria multiseleccionables.
http://www.w3.org/TR/wai-aria/roles#listbox
http://www.w3.org/TR/wai-aria/states_and_properties#aria -multiselectable

Yo mismo haría un parche, pero no estoy tan caliente en js.

Mi PR vinculado anteriormente proporciona una solución a través de un enfoque mucho más simple centrado en los principios de mejora progresiva en lugar de hacer un "análisis profundo" para hacer un widget completamente accesible a partir de la base de código elegida actual. Doy la bienvenida a todos y cada uno de los comentarios.

¿Por qué concentrarse en ARIA cuando todavía no es compatible correctamente con IE8? Desafortunadamente, este navegador de 5 años todavía se encuentra en la lista de navegadores comunes. Esto significa que mientras se somete a un escaneo de accesibilidad, una implementación que depende de ARIA fallará.

¿Por qué no utilizar un método alternativo que simplemente deshabilita los elegidos por completo y proporciona al usuario la selección original? Esto podría lograrse agregando un enlace (oculto) que usaría un pequeño fragmento de código javascript que deshabilita el elegido.

Recurso sobre la compatibilidad con IE8 ARIA: http://www.w3.org/TR/WCAG20-TECHS/wai-aria_notes.html

Puede simplemente hacer detección de navegador / función y no usar Chosen cuando se usa IE8.

@ Daniel15 Eso probablemente sería incluso una solución más fácil. Gracias por compartir tus pensamientos. En mi publicación, solo estaba tratando de señalar que implementar ARIA (por ahora) no significa que sea accesible y esté listo para su uso en aplicaciones que deben ser compatibles con WCAG 2.0.

Me encantaría ver esto funcionando. Los lectores de pantalla y los usuarios que solo utilizan el teclado realmente necesitan acceder a estos campos. No estoy tan preocupado con IE8, pero al menos una solución para los navegadores modernos sería aceptable. Me gusta bastante la idea de respaldo de IE8. Parece que hay dos buenas relaciones públicas, me encantaría ver a cualquiera de ellos fusionarse.

un gran +1 en esto por favor

+1 (+) Necesitamos tener esto en Elegido. Es un problema

aria-label (propiedad)

Define un valor de cadena que etiqueta el elemento actual. Consulte también aria-labelledby.

El propósito de aria-label es el mismo que el de aria-labelledby. Proporciona al usuario un nombre reconocible del objeto. La asignación de API de accesibilidad más común para una etiqueta es la propiedad de nombre accesible.

Si el texto de la etiqueta está visible en la pantalla, los autores DEBEN usar aria-labelledby y NO DEBEN usar aria-label. Puede haber casos en los que el nombre de un elemento no se pueda determinar mediante programación a partir del contenido del elemento, y hay casos en los que proporcionar una etiqueta visible no es la experiencia de usuario deseada. La mayoría de los lenguajes de host proporcionan un atributo que podría usarse para nombrar el elemento (por ejemplo, el atributo de título en HTML [HTML]), pero esto puede presentar una información sobre herramientas del navegador. En los casos en que una etiqueta visible o información sobre herramientas visible no sea deseable, los autores PUEDEN establecer el nombre accesible del elemento usando aria-label. Los agentes de usuario dan prioridad a aria-labelledby sobre aria-label al calcular la propiedad del nombre accesible.

@Natshah ¿Puedes hacer una solicitud de extracción con el cambio?

@Natshah en realidad, ¿puedes revisar https://github.com/harvesthq/chosen/pull/2047 para ver si lo implementa de la manera correcta?

Hola,

Tengo esto arreglado para mi caso en este enlace
https://www.drupal.org/node/2384865

Gracias.

Gratificante :)

Si. Eso debería ser como algo como en el siguiente código. .

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

Pero podemos usar este código:

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

Gracias.

Gratificante :)

¿Algún avance en esto? Recientemente implementamos elegido y obtuvimos comentarios de los usuarios que usan tecnología de asistencia "Jaws" de que no pueden usar los campos seleccionados en absoluto.

Parece un tema importante a considerar. ¿Ha habido algún movimiento en este frente?

Nada que yo sepa, desafortunadamente es muy difícil replicar los problemas dadas las combinaciones masivas de tecnologías de asistencia con navegadores y sistemas operativos ... Normalmente, siempre que pueda navegar por el teclado + tenga la implementación correcta de ARIA, debería funcionar en la mayoría de los casos.

Para una solución rápida, he recurrido a asegurarme de que los lectores de pantalla al menos puedan usar el campo de selección original. Para esto, en lugar de ocultar el elemento de selección, estoy agregando una clase screenreaders-only y aria-hidden:true en el contenedor elegido generado.

Entonces, en chosen.jquery.js líneas 599 to 605 ven así:

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

Y la línea 616 ve así:

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

No es una solución perfecta, ya que tanto la selección oculta como el widget se pueden enfocar con el teclado, pero es mucho mejor que tener un widget inaccesible.

Esto funcionó para mí.
Seguí todos los consejos anteriores y cambié la siguiente línea:

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

a:

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

Gracias

Pruébelo si funciona. La estructura debería ser así. :)

Intenté agregar algunos elementos ARIA basados ​​en el trabajo que había hecho

Tengo una rama disponible aquí que hace lo siguiente:

Etiquetas ARIA y otros atributos útiles

• Agrega los siguientes elementos aria al cuadro de entrada de búsqueda
  
  
  
  • role = "combobox"
  
  
  • Se usa para indicar que los usuarios pueden escribir para seleccionar una opción o agregar nuevos elementos a una lista.
  
  
  • aria-haspopup (implícito cuando se usa el rol de cuadro combinado)
  
  
  • Se usa para indicar que esta casilla tiene un menú relacionado
  
  
  • aria-expandido
  
  
  • Obligatorio cuando se usa el cuadro combinado, indica que la lista de resultados está visible u oculta
  
  
  • El estado debe actualizarse dinámicamente a medida que el campo elegido se activa / desactiva
  
  
  • aria-activedescendant = "id_of_highlights_option"
  
  
  • Se usa para indicar qué opciones es el valor seleccionado actualmente
  
  
  • Esto debe actualizarse ya que se selecciona una nueva opción
  
  
  • aria-owns = "id_of_list_of_options"
  
  
  • Indica la lista de opciones con las que está relacionado este cuadro de búsqueda
  
  
  • aria-autocomplete = "lista"
  
  
  • "Si un autor establece el valor de un cuadro combinado de aria-autocomplete en 'lista', los agentes de usuario DEBEN exponer los cambios en el atributo aria-activedescendant en el cuadro combinado mientras el cuadro combinado permanece enfocado. Si se produce un cambio en el atributo aria-activedescendant mientras el cuadro combinado está enfocado, las tecnologías de asistencia DEBERÍAN alertar al usuario de ese cambio, por ejemplo, hablando la alternativa de texto del nuevo elemento descendiente activo. Los autores DEBEN asociar el campo de texto del cuadro combinado con su cuadro de lista usando aria-owns ".
  
  
  • aria-labeltedby = "id_of_field_label"
  
  
  • Este es el ID del elemento de etiqueta de formulario que está reemplazando.
  
  
• Agrega los siguientes atributos a la lista de opciones
  
  
  
  • identificación
  
  
  • Un identificador simple basado en el identificador del campo de formulario al que se dirigirá el atributo aria-owns en el cuadro de entrada de búsqueda
  
  
  • role = "listbox"
  
  
  • "Un widget que permite al usuario seleccionar uno o más elementos de una lista de opciones".
  
  
• Agrega los siguientes atributos a cada opción individual en la lista de opciones
  
  
  
  • identificación
  
  
  • Un ID simple basado en el índice de la opción en la lista y el ID del campo de formulario que usará aria-activedescendant que indica el elemento seleccionado actualmente
  
  
  • role = "opción"
  
  
  • Un elemento seleccionable en una lista de selección.
  
  
  • aria-ocupada
  
  
  • La razón por la que necesitamos esto es que cuando Chosen se inicializa en un campo, _no_ crea la lista de opciones hasta que el campo se activa por primera vez.
  
  
  • Este es un problema para la tecnología de asistencia, así como para los escáneres que buscan problemas de accesibilidad. Dado que el cuadro de búsqueda (role = "combobox") ahora se está eliminando, tiene un cuadro de lista (aria-owns = "id_of_list_of_options"), el cuadro de lista (nuestra lista de resultados) _debe_ tener opciones dentro O ser eliminado como ocupado para cumplir con la especificación.
    
    
    
    
    
    • Ni siquiera estoy 100% seguro de que este sea el movimiento correcto. Ciertamente evita que los escáneres marquen los campos, pero estos no están completamente ocupados, solo que aún no hemos desarrollado las opciones.
    
    
    
  
  
  • Espero que alguien con más experiencia en A11Y pueda opinar sobre esto.
  
  
  • También consideré un enfoque más radical, que implica construir la lista de resultados cuando un campo se activa por primera vez, pero eso implica agregar un nuevo disparador a Chosen.
    
    
    
    
    
    • Este disparador fue esencialmente un paso a través del método winnow_results, que construyó los resultados de búsqueda (aún ocultos), pero hizo felices a los escáneres.
    
    
    
  
  

Estado de gestión

• Administrar el atributo aria-expandido
  
  
  
  • Para indicar cuándo los resultados de la búsqueda deben ser relevantes para la tecnología de asistencia, necesitamos alternar el atributo aria-expandido a medida que los campos se activan / desactivan.
  
  
  • La forma más fácil de hacer esto (AFAIK) es ajustar el atributo durante los métodos close_field y activate_field .
  
  
  • Un simple cambio de verdadero a falso o de falso a verdadero en cada uno de estos métodos es suficiente para mantener actualizado el estado.
  
  

Voy a comenzar a usar esta versión en varios de nuestros proyectos y seguiré actualizando mi rama con cambios a medida que obtengamos una visión más detallada de nuestros proyectos desde una vista A11Y.

Gracias a todos los que leyeron hasta aquí, sé que es mucho y, por favor, si tiene comentarios, ¡hágamelo saber! Quiero llevar esto tan lejos como sea posible.

@cooperfellows , abra una solicitud de extracción con sus cambios

@stof Hecho, pero como dije, no soy un experto en A11Y y planeo hacer más pruebas. Solo quería compartir mi primer pase estable en esto.

¿Hay alguna actualización "oficial" con esto? ¿Se han realizado cambios basados ​​en los esfuerzos de @cooperfellows ?

La razón por la que pregunto es que estamos obteniendo un número cada vez mayor de usuarios de Jaws que informan que el widget es inutilizable, lo que hace que el formulario que buscan sea inutilizable.

Podemos replicar, así que feliz de ayudar / compartir ejemplos si eso ayuda.

Se realizó la solicitud de extracción (tenía algunos problemas menores que se resolvieron después del hecho) pero aún no ha sucedido nada. La rama que estoy usando en producción en este momento está aquí:

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

Sin embargo, me encantaría recibir más comentarios. No tengo Jaws, por lo que confío en auditorías de varias herramientas en línea.

Entonces, ¿esa rama es básicamente la producción actual más sus cambios, o una versión anterior con cambios recientes que aún no se han fusionado?

(Gracias por cierto)

Sí, es cierto @wcndave. Aunque al RP le vendrían bien otros ojos para hacer una revisión.

@cooperfellows Me complace ayudar con las pruebas de accesibilidad, ya que necesito

¿Alguna actualización sobre su solicitud de extracción?

Pregunta tonta: ¿tiene una versión compilada de JavaScript que pueda descargar?
¿O necesito instalar coffeescript y compilarme?

@KITSKevinBonett ¡ Gracias por la ayuda!

Se adjunta un zip de la versión de tipo jquery y proto, tanto comprimido como sin comprimir.

compiled-a11y-chosen-jquery-proto.zip

@cooperfellows Eso fue rápido. Lo agregaré a nuestro proyecto, haré algunas pruebas y les haré saber ...

@KITSKevinBonett Ya, estoy buscando tener más ojos en él, ya que no soy un experto en A11Y. Por lo tanto, se agradece cualquier comentario (duro y positivo).

Hola @cooperfellows . He revisado tu implementación. Muy bien.

Hay algunos problemas que pueden no resolverse (fácilmente) debido a incompatibilidades entre el lector de pantalla y el navegador.

He documentado mis hallazgos en el adjunto. He hecho 1 o 2 recomendaciones menores que espero sean de utilidad.

_ACTUALIZAR_

1. Algunos de mis comentarios mencionaron funciones que son locales para nuestra implementación; las he eliminado.
2. Problema al escribir dentro de "combobox" y presionar ENTER - nuestro formulario de envío no está activado - nuevamente, este es un problema de implementación local.
3. El siguiente ZIP se ha actualizado para eliminar (1) y (2).

aria-chosen-plugin.zip

Hola @cooperfellows , ¿tenía sentido mi auditoría?

Hola @KITSKevinBonett He estado fuera durante una semana de vacaciones. Le echaré un vistazo a esto tan pronto como me ponga al día con mi otro trabajo. Gracias por los comentarios, estoy seguro de que son útiles.

@KITSKevinBonett Gracias por la auditoría, esto parece bastante completo. He desglosado mis pensamientos en función de las secciones de la auditoría que usted presentó.

Marcado HTML generado por el complemento

• ¿Hay comentarios aquí? ¿O simplemente está mostrando lo que se genera?

Comportamiento solo del teclado

• "Sin embargo, cuando se selecciona la opción, el enfoque del teclado se pierde al volver a tabular".
  
  
  
  • Estoy pensando que esto podría resolverse activando y desactivando el atributo aria-hidden a medida que ese elemento se hace visible / oculto.
  
  
  • Examinaré este enfoque.
  
  
• "Problemas de CSS deshabilitado"
  
  
  
  • La selección estándar es visible
  
  
  • No puedo recrear esto, ¿puedes darme una captura de pantalla o una transmisión de pantalla o algo así?
  
  
  • No hay señal visible al resaltar los resultados con el teclado.
  
  
  • Podríamos envolver el texto del elemento resaltado actualmente en una etiqueta <em> , que se pone en cursiva (al menos en Chrome).
    
    
    
    
    
    • El problema potencial aquí es que la búsqueda también usa <em> para indicar coincidencias de texto, por lo que me preocuparía que pudieran entrar en conflicto entre sí.
    
    
    
  
  

Lectores de pantalla

• No tengo acceso a JAWS, por lo que no podré hacer mucho aquí. Haré una prueba cuando tenga más tiempo para ver qué puedo encontrar.
• Los lectores de pantalla son el área en la que realmente agradecería más ayuda, así que gracias por el desglose detallado.

Pensamientos Aria

• Puedo eliminar el atributo haspopup, como notó, es redundante.
• La razón por la que agregué aria-busy es que, de forma predeterminada, Chosen no genera ningún elemento de lista en los div ocultos hasta que se coloca el foco.
  
  
  
  • Esto significa que el elemento role = "listbox" no tiene opciones por defecto, lo que me estaba dando problemas al escanear esto con herramientas. Al agregar el elemento aria-busy al principio, esas herramientas lo ignoran.
  
  
  • El motivo del problema es que un elemento de cuadro de lista _debe poseer_ un elemento de opción ( fuente )
  
  
  • Se elimina la primera vez que se completa la lista, por lo que me pareció una situación sin daños ni faltas.
  
  
• Agregar aria-selected parece un paso obvio, no puedo creer que me lo haya perdido. Gracias por atraparlo.
  * Pensamientos finales *
  ¿Escribió usted mismo el HTML para esta auditoría o lo creó una herramienta para usted? Es muy útil, gracias de nuevo.

@cooperfellows - respuestas a sus preguntas:

Marcado HTML

• Solo muestra lo que se genera durante cada fase del comportamiento del complemento.

Comportamiento del teclado

• El "foco perdido" está solo en Firefox. Puede agregar tabindex = "- 1" para evitar el foco y luego eliminarlo nuevamente. Entonces no necesitarías ARIA.

CSS deshabilitado

• Básicamente, el SELECT original es visible en la página y se puede utilizar con UP | Flechas ABAJO porque el comportamiento predeterminado del navegador muestra las distintas opciones a medida que navega por ellas.
• El HTML renderizado por complemento también es visible, pero el menú desplegable no indica qué "opción" está resaltada.
• Sugirió usar un EM. En su lugar, utilice STRONG: tiene un significado más semántico que EM en HTML5. Ver http://html5doctor.com/ib-em-strong-element/
• Pero no creo que este sea un problema importante, ya que los usuarios aún pueden usar SELECT.
• Ver captura de pantalla

Lectores de pantalla

• Esta es una pregunta difícil porque los resultados varían según la combinación de navegador y lector de pantalla que se utilice y de qué versiones.
• Lo que diría es que sus actualizaciones de accesibilidad al complemento en términos de roles / estados / propiedades de ARIA están alineadas con las recomendaciones de W3C / WAI. Así que son buenas noticias. :)
• Depende de los fabricantes de navegadores y lectores de pantalla asegurarse de que su software se adhiera a estos.

ARIA

• Tu explicación de "aria-busy" tiene sentido. Incluso si fuera obsoleto, no causará ningún problema al estar allí.
• Auditar HTML. Hecho a mano. He estado creando una biblioteca de componentes de interfaz de usuario / guía de estilo de vida para la empresa para la que trabajo, así que solo usé componentes de allí. No tomó mucho tiempo. La parte más difícil fue volver a escuchar toda la salida del lector de pantalla para asegurarme de que había capturado todo correctamente.

Espero que todo esto ayude con su solicitud de extracción. Ha hecho un gran trabajo con el A11Y. :)

Hola,

Soy ciego. He probado el trabajo de @cooperfellows con JAWS. Funciona perfectamente. La opción seleccionada se dice como una flecha a través de las opciones.

¿Alguna noticia sobre la fusión de esto en master?

En mi trabajo diario, utilizo MISP (Malware Information Sharing Platform - https://github.com/MISP/MISP), cuyos desarrolladores han decidido recientemente utilizar "elegido" para los cuadros combinados de autocompletar. Se ha convertido en una pesadilla para mí.

Gracias de antemano por su ayuda.

Después de algunas pruebas, puedo confirmar que la versión compilada (archivo .zip) publicada arriba (el 1 de julio de 2016) funciona.

Sin embargo, cuando pruebo la rama de @cooperfellows y luego la fusiono con harvesthq / master, las opciones del menú las habla correctamente JAWS pero la tecla ENTRAR no envía el formulario.

Hola @ obert01 ,

Esta rama está muy desactualizada con respecto a la rama cosechahq / master actual, es probable que deba revisar los cambios y ajustar mi PR para que todo vuelva a funcionar.

Intentaré llegar a esto en algún momento antes de fin de mes, estoy bastante atrasado en el trabajo en este momento.

Me encantaría que uno de los colaboradores lo vea nuevamente una vez que se actualice, así que haré ping a

Muchas gracias.

Para su información, puedo probar con todas las combinaciones de lectores de pantalla JAWS y NVDA, con el siguiente navegador: Internet Explorer 11, Google Chrome, Firefox ESR, Firefox Standard, Microsoft Edge.

¿Algún progreso en esto?

Lamento insistir, pero mi trabajo diario adolece de esta falta de accesibilidad.

Además, agregar soporte de accesibilidad permitiría que Chosen se use en los sitios web del sector público / de la administración, ya que la regulación en cada vez más países va de esta manera.

Gracias

Hola,
Tenemos una aplicación que se ha utilizado y ahora necesitamos admitir la accesibilidad, pero al pasar por esto, lo que puedo ver es que aún no se ha fusionado. Será realmente útil si @cooperfellows puede finalizar esto y fusionarse, por favor.

Hola @ obert01 y @csmuthukuda ,

Acabo de hacer actualizaciones para que mi RP esté al día con la última versión de Chosen, por favor, eche un vistazo aquí:
https://github.com/harvesthq/chosen/pull/2596

Puede obtener una copia de mi repositorio bifurcado y probarlo por su cuenta. Me encantaría recibir comentarios de la vida real.

Pasó todas las comprobaciones de TravisCI, pero no creo que cubran ningún problema de A11Y. Déjame saber lo que piensas.

Hola @cooperfellows ,
Muchas gracias por su dedicación para mantener esto vivo. Lo probaré y te haré saber los comentarios al respecto. Realmente espero que los propietarios consideren fusionar esto con el maestro. Este es un requisito obligatorio ahora.

Gracias @csmuthukuda, me encantaría que se fusionara ...

@pfiller @stof @tjschuck @koenpunt , ¿hay algo que pueda hacer para ayudar a que se

Hola @cooperfellows ,

He probado su increíble trabajo con la mayoría de los navegadores web actuales y los lectores de pantalla JAWS y NVDA. Gracias !

Navegar por las opciones con el teclado funciona bien: la respuesta de voz y braille es perfecta, lo que significa que todos los atributos de ARIA están bien definidos. Sin embargo, cuando presiono ENTER para elegir una opción, no sucede nada. No tengo suficiente experiencia con JavaScript para determinar si el problema proviene de Chosen o si está presente en la aplicación que lo usa.

Para reproducir, intente elegir una opción en un cuadro combinado Elegido solo usando el teclado: TAB para enfocar el cuadro combinado, teclas de flecha para navegar por la lista, ENTER para seleccionar.

Una vez más, muchas gracias.

Gracias por esa información @ obert01. Echaré un vistazo y veré qué puedo encontrar.

@ obert01 ¿Puedes intentar usar este violín JS para confirmar que está funcionando o no? Este violín está cargando la versión jQuery compilada de mi última confirmación.

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

Puedo navegar por ese menú desplegable con mi teclado (Chrome Latest), pero NO estoy ejecutando un lector de pantalla.

Déjame saber lo que piensas.

Hola @cooperfellows ,

No hay problema con su JS Fiddle. Por lo tanto, supongo que el problema se debe a la forma en que se usa Chosen en MISP (https://www.misp-project.org/).

Verificaré esto con el equipo del proyecto MISP.

Gracias

Gracias @ obert01. Por favor déjeme saber lo que averigüe. Podría apuntar a una incompatibilidad con una configuración específica de Chosen, por lo que si hay una forma de ver cómo lo utiliza MISP, puedo intentar echar un vistazo a su implementación.

¿Se usa el elegido en algún lugar públicamente?

@cooperfellows, ¿ podría darme una nueva compilación con los últimos cambios? No sé cómo construirla.

@ obert01 @cooperfellows Acabo de probar Fiddle con NVDA, parece que la navegación del teclado funciona perfectamente (incluida la selección con la tecla ENTER). Sin embargo, cuando navego con las teclas de flecha hacia arriba y hacia abajo, el lector de pantalla dice "________no seleccionado", es decir, "Bermudas no seleccionado". ¿Es este el comportamiento esperado?

Tengo el mismo problema que @woenlee. No es tan dañino. Pero tal vez, la forma en que se establece el atributo "seleccionado" en el elemento seleccionado debe comprobarse.

¿Cuál es el comportamiento esperado cuando "ingresa" y "sale" de un elemento de la lista? Cuándo
navega hacia abajo a un nuevo elemento, en caso de que lea en voz alta el recién seleccionado
¿ít? ¿También anuncia lo que ya NO está seleccionado? @ obert01 @woenlee

El domingo, 25 de agosto de 2019 a las 12:18 p. M. Olivier BERT [email protected]
escribió:

Tengo el mismo problema que @woenlee https://github.com/woenlee . No lo es
tan dañino. Pero tal vez, la forma en que se establece el atributo "seleccionado" en el
se debe marcar el elemento seleccionado.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/harvesthq/chosen/issues/264?email_source=notifications&email_token=ABT3ZTIESGLX6IYW4BF2QCLQGKWDVA5CNFSM4AATGGB2YY3PNVWWK3TUL52HS4DFVREXG43VMDVBW63WL2 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABT3ZTMH2KUYYE7HNO2UGH3QGKWDVANCNFSM4AATGGBQ
.

-
~ Cooper

@cooperfellows Después de ejecutar algunas pruebas de accesibilidad de ax, parece que encontré un error en su PR, lo que explica por qué estaba haciendo eso. En la línea 342 de Abstract-chosen.coffee, la entrada tiene 2 roles asignados, "cuadro combinado" y "cuadro de lista".

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

Después de dar el

Pagar a los clientes de Harvest aquí y probar para que sea accesible internamente se encontró con esto. La accesibilidad es imprescindible, y dejaremos Harvest si esto no se soluciona, si un mantenedor de Harvest no muestra al menos algo de apoyo pronto.

@ obert01 ¿Puedes intentar usar este violín JS para confirmar que está funcionando o no? Este violín está cargando la versión jQuery compilada de mi última confirmación.

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

Puedo navegar por ese menú desplegable con mi teclado (Chrome Latest), pero NO estoy ejecutando un lector de pantalla.

Déjame saber lo que piensas.

@cooperfellows
Estaba probando este JS Fiddle con JAWS 2019 y experimenté algo ligeramente diferente al navegar por las opciones con las teclas de flecha hacia arriba y hacia abajo.
En Google Chrome 71.0.3578.98:
JAWS no leería el valor resaltado actual a menos que la lista hiciera algún desplazamiento / representación. es decir, si la lista se muestra

<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 opciones, JAWS no lee la opción resaltada al presionar hacia abajo hasta que llegue a la décima opción enAntigua y Barbuda . El cuadro hace un pequeño desplazamiento automático para resaltar Antigua y Barbuda y luego lee la opción.

En IE 11.0.9600.19463: Navegar con las teclas de flecha parece leer la opción resaltada actual correctamente subiendo y bajando. No requiere ningún tipo de renderizado.

Me gustaría saber si alguien más ha experimentado esto. @ obert01 @woenlee

Hola y gracias por tu trabajo.

Desafortunadamente, esto no funciona correctamente. Es extremadamente difícil de describir, ya que el comportamiento cambia en función del navegador o lector de pantalla utilizado.

Creo que algunas propiedades de aria no están presentes o no están actualizadas. Aquí los problemas generales que encuentro:

• Problema de desplazamiento: cuando llego la flecha hacia abajo y llego al final de la lista visible de elementos, tengo que presionar dos veces la flecha hacia abajo para enfocar el siguiente elemento.
• Cuando presiono ENTER para seleccionar un elemento, el enfoque no se libera. El comportamiento esperado sería que el lector de pantalla vuelva al modo de navegación rápida y me deje leer el resto de la página web. En cambio, las teclas de flecha siguen controlando mi elección en la lista.
• Los guiones actuales no permiten saber si se muestran propuestas y cuántas son. En los complementos seleccionados más accesibles que conozco, JAWS / NVDA anuncia cuántos resultados coinciden con la cadena ingresada en la entrada de texto.
• Por último, tengo la impresión de que JAWS no comprende si la lista está combinada o ampliada. A veces, después de hacer una elección con ENTER e intentar leer el resto de la página, JAWS sigue leyendo las últimas propuestas que se han mostrado.

Buenos puntos:

• La parte de autocompletar funciona bien. Si escribo "fra", JAWS pronuncia "Francia" y puedo presionar ENTER para seleccionar.
• Los elementos se leen correctamente como flecha en la lista.

Lamentablemente, no sé muchas cosas sobre ARIA, JavaScript y la web en general. Le sugiero que se asegure de que el máximo de propiedades ARIA esté configurado y actualizado correctamente.

A continuación, encontrará la demostración y el código de un complemento de JQuery que interactúa perfectamente con los lectores de pantalla:
https://a11y.nicolas-hoffmann.net/autocomplete-list/

Lamento no poder ayudar más.

No dudes en publicar nuevas demostraciones de tu trabajo. Estoy feliz de probarlo por ti.