Chosen: Problemas de acessibilidade com Chosen

peça relevante dessa discussão:

Muita coisa precisa ser trabalhada. Parece que a acessibilidade não foi considerada em
tudo neste widget, portanto, muito trabalho WAI-ARIA e JS seria necessário para *
tente * fazer com que isso esteja em conformidade com as WCAG 2.0.

O maior problema, de uma revisão de 30 segundos com FF6 / JAWS12 é que o
componente é representado como um tipo de entrada = texto seguido por uma lista não ordenada
de todas as opções (243 para países) que o usuário precisa para navegar
até mesmo ignorar o campo.

O campo de texto de pesquisa pode usar um rótulo, para começar, mas isso é fácil de corrigir.

Um problema maior é que os itens de lista gerados não têm âncoras ... os usuários de leitores de tela podem agir se souberem para que servem os itens da lista?

Este é um plug-in muito bom! Eu realmente gosto da funcionalidade.
Haverá algum desenvolvimento futuro para melhorar a acessibilidade? Adicionando WAI-ARIA para torná-lo compatível com WCAG 2.0 ???

Acabei de ler este artigo no site do grupo filamentos. As funções ARIA podem ser úteis para Escolhidos:
http://filamentgroup.com/lab/jquery_ipod_style_and_flyout_menus/

Por exemplo: os resultados escolhidos UL teriam role = "menu" aria-activedescendant = "active-menuitem" aplicado a eles e os resultados <li> teriam role = "menuitem".
A caixa de pesquisa no menu suspenso Escolhido provavelmente também precisaria de algum tipo de função ARIA ??

@dotdreaming você aponta para a documentação certa, mas as funções que você menciona não estão totalmente corretas.

Acho que as seguintes funções devem ser usadas:

• combobox .
• opção

Acho que seria muito legal se alguém realmente mergulhasse na documentação WAI-ARIA e a aplicasse aos escolhidos.

Se eu conseguir encontrar tempo, posso fazer isso sozinho. Não parece que seria muito difícil de fazer.

Algum movimento para incluir o ARIA neste projeto?

Mesmo que funcione com tecnologia assistiva, também precisa ser testado para ver se funciona apenas com usuários de teclado.

A propósito, esta é apenas uma maneira de verificar o que há de mais fácil para melhorias de acessibilidade, mas WAVE identificou algumas coisas básicas que devem ser limpas -> http://wave.webaim.org/report?url=http%3A% 2F% 2Fharvesthq.github.com% 2Fchosen% 2F & js = 2

Algum desses problemas de acessibilidade foi resolvido? Eu realmente gosto de usar isso em nosso site principal da universidade, mas esses problemas de acessibilidade me desanimam

+1 - Recebemos feedback de um usuário cego que as listas suspensas Escolhidas são difíceis de usar e estão tendo dificuldades para selecionar opções. Eles estão usando o JAWS 14 como leitor de tela.

Tentei usar apenas um teclado apenas para navegação. A seleção de itens funciona muito bem e de forma intuitiva (para baixo para abrir a lista de um novo item, para cima / baixo para navegar na lista, esc para fechar a lista, digite para selecionar). Remover itens da multisseleção era simples (backspace), no entanto, limpar uma lista suspensa de seleção única apresentava mais desafios. Parece que, depois de selecionar um item, posso pressionar para baixo para abrir a lista novamente e navegar para cima até que nenhuma opção seja selecionada (semelhante a uma lista suspensa normal funciona se seu primeiro item estiver em branco como os exemplos), mas estou incapaz de pressionar Enter para selecionar a opção nula. Algum método para desmarcar uma opção completamente (ou pelo menos uma opção padrão em branco) seria muito útil.

Também não tenho certeza se vale a pena, mas percebi que os dados ainda estão armazenados no controle de seleção oculto (presumo que seja assim que são passados ​​para o formulário). Pode valer a pena atualizar o menu suspenso Escolhido quando o select for alterado também - eu estava debatendo se isso satisfaria os critérios 4.1.2 das WCAG, uma vez que UAs podem interagir com o controle de seleção programaticamente e poderíamos tratar Escolhido como uma fachada em topo dele para efeitos de acessibilidade.

para a segunda parte, solicitamos acionar listz:updated mesmo quando você altera o valor do controle de seleção programaticamente para atualizar o escolhido.
Isso é necessário porque os navegadores não disparam um evento quando o valor é alterado programaticamente para permitir que Chosen saiba sobre isso (e se eles estivessem fazendo isso, ainda teríamos que evitar loops infinitos, pois também o estamos alterando programaticamente)

Vou analisar como adicionar acessibilidade hoje. @marklagendijk Acho que o que você mencionou é a melhor maneira de entrar no caixa eletrônico. Vou atualizar minhas descobertas.

Isso pode ser útil ou não, mas temos diretrizes de acessibilidade rígidas a seguir e com a versão 1.0.0 o testador de acessibilidade de nosso cliente voltou com os seguintes comentários:

1. o 'select' associado ao 'rótulo' exibe: nenhum; e então o
   'rótulo' é efetivamente órfão. O 'div class = "escolhido-recipiente-único"' que leva
   seu lugar como o controle de formulário não tem nenhum nome ou rótulo programático acessível.

2. Não há foco visível na lista suspensa falsa.

1. Não há foco visível no link na lista suspensa falsa.

Estou usando isso em conjunto com o módulo Drupal Chosen. Também temos um testador cego que notou que, ao acessar a entrada, não sabia que era capaz de digitar, nem os resultados retornados, incluindo "Nenhum resultado encontrado".

@marklagendijk
Qualquer progresso nesta questão. Estou tentando reintroduzir o problema para adicionar Chosen ao núcleo do Drupal e este é o principal bloqueador.

Encontrei um exemplo muito bom de como isso pode ser feito aqui:
http://cookiecrook.com/test/aria/multiselect/listbox.html
Aqui está o javascript: http://cookiecrook.com/test/aria/multiselect/js/aria.js

Eu acredito que isso mapeia quase exatamente para a funcionalidade básica escolhida. Parece muito simples de implementar usando a caixa de listagem e as propriedades de ária multisselecionáveis
http://www.w3.org/TR/wai-aria/roles#listbox
http://www.w3.org/TR/wai-aria/states_and_properties#aria -multiselectable

Eu mesmo faria um patch, mas não sou tão bom em js.

Meu PR no link acima fornece uma solução por meio de uma abordagem muito mais simples centrada nos princípios de aprimoramento progressivo em vez de dar um "mergulho profundo" em fazer um widget completamente acessível a partir da base de código Chosen atual. Eu agradeço todo e qualquer feedback.

Por que focar no ARIA quando ele ainda não é compatível com o IE8? Infelizmente, este navegador de 5 anos ainda está na lista de navegadores comuns. Isso significa que, ao passar por uma varredura de acessibilidade, uma implementação que depende do ARIA falhará.

Por que não usar um método de fallback que simplesmente desativa o escolhido completamente e fornece ao usuário a seleção original? Isso poderia ser alcançado adicionando um link (oculto) que usaria um pequeno pedaço de código javascript que desabilita o escolhido.

Recurso relacionado ao suporte ARIA do IE8: http://www.w3.org/TR/WCAG20-TECHS/wai-aria_notes.html

Você poderia apenas fazer a detecção do navegador / recurso e não usar o Chosen quando o IE8 for usado.

@ Daniel15 Isso provavelmente seria uma solução ainda mais fácil. Obrigado por compartilhar seus pensamentos. Em minha postagem, eu estava apenas tentando apontar que implementar ARIA (por enquanto) não significa que ele está acessível e pronto para uso em aplicativos que precisam ser compatíveis com WCAG 2.0.

Adoraria ver isso funcionando. Leitores de tela e usuários apenas com teclado realmente precisam acessar esses campos. Não estou tão preocupado com o IE8, mas pelo menos uma solução para navegadores modernos seria aceitável. Eu gosto bastante da ideia do substituto do IE8. Parece que há dois bons PRs - adoraria ver qualquer um deles mesclados.

um grande +1 nisso, por favor

+1 (+) Precisamos ter isso em Escolhido. É um problema

aria-label (propriedade)

Define um valor de string que rotula o elemento atual. Veja também aria-labelledby.

O propósito de aria-label é o mesmo de aria-labelledby. Ele fornece ao usuário um nome reconhecível do objeto. O mapeamento de API de acessibilidade mais comum para um rótulo é a propriedade de nome acessível.

Se o texto do rótulo estiver visível na tela, os autores DEVEM usar aria-labelledby e NÃO DEVEM usar aria-label. Pode haver casos em que o nome de um elemento não pode ser determinado programaticamente a partir do conteúdo do elemento e há casos em que fornecer um rótulo visível não é a experiência do usuário desejada. A maioria das linguagens de host fornece um atributo que pode ser usado para nomear o elemento (por exemplo, o atributo title em HTML [HTML]), mas isso pode apresentar uma dica de ferramenta do navegador. Nos casos em que um rótulo visível ou dica de ferramenta visível é indesejável, os autores PODEM definir o nome acessível do elemento usando aria-label. Os agentes do usuário dão precedência a aria-labelledby sobre aria-label ao calcular a propriedade de nome acessível.

@Natshah Você pode fazer uma solicitação de pull com a mudança?

@Natshah , na verdade, você pode revisar https://github.com/harvesthq/chosen/pull/2047 para ver se ele implementa da maneira certa?

Oi,

Eu tenho isso corrigido para o meu caso neste link
https://www.drupal.org/node/2384865

Obrigado.

Recompensador :)

sim. Isso deve ser algo como no código a seguir. .

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

Mas 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()));
        });

Obrigado.

Recompensador :)

alguma atualização disso? Recentemente, implementamos o escolhido e recebemos feedback dos usuários que usam a tecnologia assisstive "Jaws" de que eles não podem usar os campos selecionados.

Parece ser uma questão importante a ser examinada. Houve algum movimento nesta frente?

Nada que eu saiba, infelizmente é muito difícil replicar problemas devido às combinações massivas de tecnologias assistivas com navegadores e sistemas operacionais ... Normalmente, desde que você possa navegar pelo teclado + você tenha a implementação correta do ARIA, deve funcionar na maioria dos casos.

Para uma solução rápida, recorri a garantir que os leitores de tela pelo menos usem o campo de seleção original. Para isso, em vez de ocultar o elemento selecionado, estou adicionando uma classe screenreaders-only e aria-hidden:true no contêiner escolhido gerado.

Então, em chosen.jquery.js linhas 599 to 605 tem esta aparência:

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

E a linha 616 parece com isto:

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

Não é uma solução perfeita, já que tanto a seleção oculta quanto o widget podem ser focalizados no teclado, mas é muito melhor do que ter um widget inacessível.

Isso funcionou para mim.
Segui todos os conselhos acima e mudei a seguinte linha:

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

para:

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

Obrigado

Tente se der certo. A estrutura deve ser assim. :)

Tentei adicionar alguns elementos ARIA baseados no trabalho que

Tenho um branch disponível aqui que faz o seguinte:

Marcadores ARIA e outros atributos úteis

• Adiciona os seguintes elementos de ária à caixa de entrada de pesquisa
  
  
  
  • role = "combobox"
  
  
  • Usado para indicar que os usuários podem digitar para selecionar uma opção ou adicionar novos elementos a uma lista
  
  
  • aria-haspopup (implícito ao usar a função combobox)
  
  
  • Usado para indicar que esta caixa tem um menu relacionado
  
  
  • ária expandida
  
  
  • Obrigatório ao usar a combobox, indica que a lista de resultados está visível ou oculta
  
  
  • O estado precisa ser atualizado dinamicamente conforme o campo escolhido é ativado / desativado
  
  
  • aria-activedescendant = "id_of_highlighted_option"
  
  
  • Usado para indicar quais opções é o valor atualmente selecionado
  
  
  • Isso precisa ser atualizado conforme uma nova opção é selecionada
  
  
  • aria-owns = "id_of_list_of_options"
  
  
  • Indica a lista de opções às quais esta caixa de pesquisa está relacionada
  
  
  • aria-autocomplete = "lista"
  
  
  • "Se um autor definir o valor do combobox de aria-autocomplete como 'list', os agentes do usuário DEVEM expor as alterações no atributo aria-activedescendant no combobox enquanto o combobox permanece em foco. Se ocorrer uma alteração no atributo aria-activedescendant durante o combobox está focado, as tecnologias assistivas DEVEM alertar o usuário dessa mudança, por exemplo, falando a alternativa em texto do novo elemento descendente ativo. Os autores DEVEM associar o campo de texto combobox com sua caixa de listagem usando aria-owns. "
  
  
  • aria-Labelby = "id_of_field_label"
  
  
  • Este é o ID do elemento de etiqueta do formulário que escolheu está substituindo
  
  
• Adiciona os seguintes atributos à lista de opções
  
  
  
  • identificação
  
  
  • Um ID simples baseado no ID do campo do formulário a ser direcionado pelo atributo aria-owns na caixa de entrada de pesquisa
  
  
  • papel = "caixa de listagem"
  
  
  • "Um widget que permite ao usuário selecionar um ou mais itens de uma lista de opções."
  
  
• Adiciona os seguintes atributos a cada opção individual na lista de opções
  
  
  
  • identificação
  
  
  • Um ID simples baseado no índice da opção na lista e o ID do campo do formulário a ser usado pelo aria-activedescendant que indica o elemento atualmente selecionado
  
  
  • papel = "opção"
  
  
  • Um item selecionável em uma lista de seleção.
  
  
  • ária ocupada
  
  
  • A razão pela qual precisamos disso é que quando Chosen é inicializado em um campo, ele _não_ constrói a lista de opções até que o campo seja ativado pela primeira vez.
  
  
  • Este é um problema para a tecnologia assitive, bem como para scanners que procuram problemas de acessibilidade. Uma vez que a caixa de pesquisa (role = "combobox") agora está delcarando, ela possui uma caixa de listagem (aria-owns = "id_of_list_of_options"), a caixa de listagem (nossa lista de resultados) _deve_ ter opções dentro dela OU ser declarada como ocupada para cumprir a especificação.
    
    
    
    
    
    • Não tenho nem 100% de certeza de que esse é o movimento certo. Certamente evita que os campos sejam sinalizados por scanners, mas eles não estão totalmente ocupados, apenas ainda não criamos as opções.
    
    
    
  
  
  • Espero que alguém com mais experiência A11Y possa opinar sobre isso.
  
  
  • Também considerei uma abordagem mais radical, que envolve construir a lista de resultados quando um campo é ativado pela primeira vez, mas que envolve adicionar um novo gatilho a Chosen.
    
    
    
    
    
    • Esse gatilho era essencialmente uma passagem para o método winnow_results, que criava os resultados da pesquisa (ainda oculto), mas deixava os scanners felizes.
    
    
    
  
  

Estado Administrativo

• Gerenciando o atributo ária expandido
  
  
  
  • Para indicar quando os resultados da pesquisa devem ser relevantes para a tecnologia assitive, precisamos alternar o atributo ária expandido conforme os campos são ativados / desativados.
  
  
  • A maneira mais fácil de fazer isso (AFAIK) é ajustar o atributo durante os métodos close_field e activate_field .
  
  
  • Uma simples mudança de verdadeiro para falso ou falso para verdadeiro em cada um desses métodos é suficiente para manter o estado atualizado
  
  

Vou começar a usar esta versão em vários de nossos projetos e continuarei atualizando meu branch com as mudanças à medida que tivermos uma visão mais detalhada de nossos projetos a partir de uma visão A11Y.

Obrigado a todos que leram até aqui, eu sei que é muito e por favor, se vocês tiverem comentários, me avisem! Quero levar isso o mais longe possível.

@cooperfellows abra uma solicitação pull com suas alterações

@stof Pronto, mas como eu disse, não sou nenhum especialista em A11Y e pretendo fazer mais alguns testes. Eu só queria compartilhar minha primeira passagem estável nisso.

Existe alguma atualização "oficial" com isso? Alguma mudança foi feita com base nos esforços de @cooperfellows ?

A razão pela qual pergunto é que estamos obtendo um número cada vez maior de usuários do Jaws relatando o widget como inutilizável, efetivamente tornando a forma que eles estão olhando inutilizável.

Podemos replicar, tão feliz em ajudar / compartilhar exemplos, se isso ajudar?

A solicitação de pull foi feita (ela tinha alguns problemas menores que foram resolvidos após o fato), mas nada aconteceu ainda. O ramo que estou usando na produção agora está aqui:

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

Eu adoraria algum outro feedback, no entanto. Não tenho Jaws, então conto com auditorias de várias ferramentas online.

Então esse branch é basicamente a produção atual mais suas alterações, ou uma versão anterior com alterações recentes ainda não integradas?

(Obrigado BTW)

Sim, isso mesmo, @wcndave. Embora o PR realmente pudesse usar alguns outros olhos para revisão.

@cooperfellows Estou feliz em ajudar nos testes de acessibilidade, pois preciso portar uma implementação escolhida existente para uma nova construção que precisa atender às WCAG 2.

Alguma atualização em sua solicitação de pull?

Pergunta boba - você tem uma versão compilada do JavaScript que eu possa baixar?
Ou preciso instalar o coffeescript e me compilar?

@KITSKevinBonett Obrigado pela ajuda!

Em anexo está um zip da versão jquery e prototipo, compactado e não compactado.

compiled-a11y-chosen-jquery-proto.zip

@cooperfellows Isso foi rápido. Vou adicionar ao nosso projeto, fazer alguns testes e informá-lo ...

@KITSKevinBonett Sim , estou tentando dar mais atenção a ele, já que não sou nenhum especialista em A11Y. Portanto, qualquer feedback (severo e positivo) é apreciado.

Olá @cooperfellows - eu revisei sua implementação - muito boa mesmo.

Existem alguns problemas que podem não ser (facilmente) resolvidos devido a incompatibilidades de leitor de tela / navegador.

Documentei minhas descobertas no anexo. Fiz 1 ou 2 pequenas recomendações que espero que sejam úteis.

_ATUALIZAR_

1. Alguns de meus comentários mencionaram a funcionalidade local para nossa implementação - eu os removi.
2. Problema ao digitar dentro de "combobox" e pressionar ENTER - nosso envio de formulário não está sendo ativado - novamente, este é um problema de implementação local.
3. O ZIP abaixo foi atualizado para remover (1) e (2).

aria-chosen-plugin.zip

Olá @cooperfellows - minha auditoria fez sentido?

Olá, @KITSKevinBonett , estive fora por uma semana de férias. Vou dar uma olhada nisso assim que estiver em dia com meu outro trabalho. Obrigado pelo feedback, tenho certeza de que é útil.

@KITSKevinBonett Obrigado pela auditoria, isso parece muito completo. Eu dividi meus pensamentos com base nas seções da auditoria conforme você as expôs.

Marcação HTML gerada pelo plugin

• Existe algum feedback aqui? Ou você está apenas mostrando o que é gerado?

Comportamento apenas do teclado

• "No entanto, quando a opção é selecionada, o foco do teclado se perde na tabulação novamente."
  
  
  
  • Estou pensando que isso poderia ser resolvido alternando o atributo aria-hidden ativado e desativado conforme esse elemento se torna visível / oculto?
  
  
  • Vou examinar essa abordagem.
  
  
• "Problemas com CSS Desativado"
  
  
  
  • A seleção padrão é visível
  
  
  • Não consigo recriar isso, você pode me dar uma captura de tela ou transmissão de tela ou algo assim?
  
  
  • Nenhuma sugestão visível ao destacar os resultados com o teclado.
  
  
  • Poderíamos envolver o texto do item atualmente destacado em uma tag <em> , que fica em itálico (pelo menos no Chrome).
    
    
    
    
    
    • O problema potencial aqui é que a pesquisa também usa <em> para indicar correspondências de texto, portanto, estou preocupado que possam entrar em conflito uma com a outra.
    
    
    
  
  

Leitores de tela

• Não tenho acesso ao JAWS, então não poderei fazer muito aqui. Vou fazer um teste quando tiver mais tempo para ver o que posso encontrar.
• Leitores de tela são a área em que eu realmente gostaria de receber mais ajuda, então, obrigado pela análise detalhada.

Pensamentos de Aria

• Posso remover o atributo haspopup, como você observou, é redundante.
• A razão pela qual adicionei aria-busy é que, por padrão, Chosen não gera nenhum elemento de lista nos divs ocultos até que o foco seja colocado.
  
  
  
  • Isso significa que o elemento role = "listbox" não tem opções por padrão, o que estava me causando problemas ao verificar isso com ferramentas. Ao adicionar o elemento aria-busy no início, ele é ignorado por essas ferramentas.
  
  
  • O motivo do problema é que um elemento da caixa de listagem _deve possuir_ um elemento de opção ( fonte )
  
  
  • Ele é removido na primeira vez que a lista é preenchida, então me pareceu uma situação sem danos e sem problemas.
  
  
• Adicionar ária selecionada parece um passo óbvio, não acredito que perdi isso. Obrigado por pegá-lo.
  * Reflexões finais *
  Você mesmo escreveu o HTML para esta auditoria ou uma ferramenta o criou para você? É muito útil, então, obrigado novamente.

@cooperfellows - respostas às suas perguntas:

Marcação HTML

• Apenas mostrando o que é gerado durante cada fase de comportamento do plugin.

Comportamento do teclado

• O "foco perdido" está apenas no Firefox. Você pode adicionar tabindex = "- 1" para evitar o foco e, em seguida, removê-lo novamente. Então você não precisaria do ARIA.

CSS desabilitado

• Basicamente, o SELECT original é visível na página e pode ser usado com UP | Setas PARA BAIXO porque o comportamento padrão do navegador mostra as várias opções à medida que você navega por elas.
• O HTML renderizado por plug-in também está visível, mas a lista suspensa não indica qual "opção" está destacada.
• Você sugeriu usar um EM. Em vez disso, use STRONG - tem um significado mais semântico do que EM em HTML5. Consulte http://html5doctor.com/ib-em-strong-element/
• Mas não acho que seja um grande problema, pois os usuários ainda podem usar o SELECT.
• Veja a imagem

Leitores de tela

• Isso é difícil porque os resultados variam dependendo de qual combinação de navegador e leitor de tela está sendo usada e de quais versões.
• O que eu diria é que suas atualizações de acessibilidade para o plugin em termos de funções / estados / propriedades ARIA estão alinhadas com as recomendações W3C / WAI. Então, isso é uma boa notícia. :)
• Cabe aos fabricantes de navegadores e leitores de tela garantir que seus softwares cumpram esses requisitos.

ÁRIA

• Sua explicação para "ária ocupada" faz sentido. Mesmo se estiver obsoleto, não causará problemas por estar lá.
• HTML de auditoria. Feito à mão. Estou construindo uma biblioteca de componentes de interface do usuário / guia de estilo de vida para a empresa para a qual trabalho, então usei apenas os componentes de lá. Não demorou muito. A parte mais difícil foi ouvir novamente toda a saída do leitor de tela para ter certeza de que havia capturado tudo corretamente.

Espero que tudo isso ajude com sua solicitação de pull. Você fez um ótimo trabalho com o A11Y. :)

Olá,

Eu sou cego. Testei o trabalho de

Alguma notícia sobre a fusão disso no master?

No meu trabalho diário, eu uso MISP (Malware Information Sharing Platform - https://github.com/MISP/MISP), cujos desenvolvedores decidiram recentemente usar "escolhido" para caixas de combinação de preenchimento automático. Isso se tornou um pesadelo para mim.

Agradeço antecipadamente por sua ajuda.

Após alguns testes, posso confirmar que a versão compilada (arquivo .zip) postada acima (em 1 de julho de 2016) funciona.

No entanto, quando tento o branch de clono o @cooperfellows e mesclo com harvesthq / master, as opções de menu são faladas corretamente pelo JAWS, mas a tecla ENTER não envia o formulário.

Olá @ obert01 , muito obrigado por dar uma olhada nisso usando o JAWS, essa foi uma grande parte que estava faltando durante meu trabalho.

Este branch está muito desatualizado em relação ao branch atual harvesthq / master, provavelmente terei de revisar as alterações e ajustar meu PR para colocar as coisas de volta em um estado de funcionamento.

Vou tentar fazer isso antes do final do mês, estou bastante sobrecarregado de trabalho agora.

Eu adoraria ter um dos colaboradores observando novamente assim que for atualizado, então irei dar um ping em

Muito obrigado.

Para sua informação, posso testar com todas as combinações de leitores de tela JAWS e NVDA, com o seguinte navegador: Internet Explorer 11, Google Chrome, Firefox ESR, Firefox Standard, Microsoft Edge.

Algum progresso nisso?

Lamento insistir, mas meu trabalho diário sofre com essa falta de acessibilidade.

Além disso, adicionar suporte de acessibilidade permitiria que Chosen fosse usado em sites do setor público / administração, uma vez que a regulamentação em cada vez mais países está acontecendo dessa forma.

Obrigada

Oi,
Temos um aplicativo que usou o escolhido e agora precisamos oferecer suporte à acessibilidade, mas ao passar por isso o que posso ver é que ainda não foi mesclado. Será muito útil se @cooperfellows puder finalizar isso e mesclar, por favor.

Olá @ obert01 e @csmuthukuda ,

Acabei de fazer atualizações para atualizar meu RP com a versão mais recente do Chosen, por favor, dê uma olhada aqui:
https://github.com/harvesthq/chosen/pull/2596

Você pode obter uma cópia do meu repositório bifurcado e testá-lo. Eu adoraria algum feedback da vida real.

Ele passou em todas as verificações do TravisCI, mas não acho que eles cobrem nenhum problema do A11Y. Diz-me o que pensas.

Olá @cooperfellows ,
Muito obrigado pela sua dedicação em manter isso vivo. Vou testar isso e deixar você saber o feedback disso. Eu realmente espero que os proprietários considerem a fusão com o master. Este é um requisito obrigatório agora.

Obrigado @csmuthukuda , adoraria que fosse fundido em ....

@pfiller @stof @tjschuck @koenpunt , algo que eu possa fazer para ajudar a resolver isso? É realmente uma peça que faltava para um sistema inacreditavelmente incrível.

Olá @cooperfellows ,

Testei seu trabalho incrível com a maioria dos navegadores da web atuais e os leitores de tela JAWS e NVDA. Obrigada !

Percorrer as opções com o teclado funciona bem: o feedback de fala e braille é perfeito, o que significa que todos os atributos ARIA estão bem definidos. No entanto, quando pressiono ENTER para escolher uma opção, nada acontece. Não tenho experiência suficiente com JavaScript para determinar se o problema vem de Chosen ou se está presente no aplicativo que o usa.

Para reproduzir, tente escolher uma opção na caixa de combinação escolhida usando apenas o teclado: TAB para colocar o foco na caixa de combinação, teclas de seta para navegar na lista, ENTER para selecionar.

Mais uma vez, muito obrigado.

Obrigado por essa informação @ obert01. Vou dar uma olhada e ver o que posso encontrar.

@ obert01 Você pode tentar usar este fiddle JS para confirmar se ele está funcionando / não está funcionando? Este violino está carregando a versão jQuery compilada do meu último commit.

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

Consigo navegar nessa lista suspensa usando meu teclado (Chrome Latest), mas NÃO estou executando um leitor de tela.

Diz-me o que pensas.

Olá @cooperfellows ,

Nenhum problema com seu JS Fiddle. Portanto, suponho que o problema seja devido à forma como Chosen é usado no MISP (https://www.misp-project.org/).

Vou verificar isso com a equipe do projeto MISP.

Obrigado

Obrigado @ obert01. Por favor, deixe-me saber o que você descobrir. Isso pode apontar para uma incompatibilidade com uma configuração específica de Chosen, portanto, se houver uma maneira de ver como o MISP o utiliza, posso tentar dar uma olhada em sua implementação.

O escolhido é usado em algum lugar publicamente?

@cooperfellows você pode por favor me dar uma nova compilação com as últimas mudanças que eu não sei como compilar.

@ obert01 @cooperfellows Acabei de experimentar o Fiddle com o NVDA, parece que a navegação do teclado funciona perfeitamente (incluindo a seleção com a tecla ENTER). No entanto, quando eu navego com as teclas de seta para cima e para baixo, o leitor de tela lê, "________não selecionado", ou seja, "Bermuda não selecionada". Este é o comportamento esperado?

Tenho o mesmo problema que @woenlee. Não é tão prejudicial. Mas talvez, a maneira como o atributo "selecionado" é definido no item selecionado deva ser verificada.

Qual é o comportamento esperado quando você "entra" e "sai" de um item da lista? Quando
você navegar para baixo em um novo item, ele deve ler o recém-selecionado
item? Também anuncia o que NÃO está mais selecionado? @ obert01 @woenlee

No domingo, 25 de agosto de 2019 às 12h18 Olivier BERT [email protected]
escreveu:

Tenho o mesmo problema que @woenlee https://github.com/woenlee . Não é
tão prejudicial. Mas talvez, a forma como o atributo "selecionado" é definido no
o item selecionado deve ser verificado.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/harvesthq/chosen/issues/264?email_source=notifications&email_token=ABT3ZTIESGLX6IYW4BF2QCLQGKWDVA5CNFSM4AATGGB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CWTYY#issuecomment-524642787 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABT3ZTMH2KUYYE7HNO2UGH3QGKWDVANCNFSM4AATGGBQ
.

-
~ Cooper

@cooperfellows Depois de executar alguns testes de acessibilidade do machado, parece que encontrei um bug em seu PR, o que explica por que ele estava fazendo isso. Na linha 342 de Abstract-chosen.coffee, a entrada tem 2 funções atribuídas a ela, "combobox" e "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>

Depois de dar o

Pagar clientes da Harvest aqui e testar para ser acessível internamente deu errado. Acessibilidade é uma necessidade, e nós sairemos do Harvest se isso não for resolvido, se um mantenedor com o Harvest não mostrar pelo menos algum suporte para isso em breve.

@ obert01 Você pode tentar usar este fiddle JS para confirmar se ele está funcionando / não está funcionando? Este violino está carregando a versão jQuery compilada do meu último commit.

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

Consigo navegar nessa lista suspensa usando meu teclado (Chrome Latest), mas NÃO estou executando um leitor de tela.

Diz-me o que pensas.

@cooperfellows
Eu estava testando este JS Fiddle com JAWS 2019 e experimentei algo um pouco diferente ao navegar pelas opções com as teclas de seta para cima e para baixo.
No Google Chrome 71.0.3578.98:
O JAWS não leria o valor realçado atual, a menos que a lista fizesse alguma rolagem / renderização. ou seja, se a lista estiver sendo exibida

<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 opções, o JAWS não lê a opção destacada ao pressionar para baixo até chegar à 10ª opção emAntigua e Barbuda . A caixa rola automaticamente para destacar Antígua e Barbuda e, em seguida, lê a opção.

No IE 11.0.9600.19463: Navegar com as teclas de seta parece ler a opção realçada atual indo para cima e para baixo corretamente. Não requer algum tipo de renderização.

Gostaria de saber se mais alguém passou por isso. @ obert01 @woenlee

Olá e obrigado pelo seu trabalho.

Infelizmente, isso não funciona corretamente. É extremamente difícil de descrever, pois o comportamento muda em função do navegador ou leitor de tela utilizado.

Acho que algumas propriedades da ária não estão presentes ou não foram atualizadas. Aqui estão os problemas gerais que encontro:

• Problema de rolagem: quando eu coloco a seta para baixo e chego ao final da lista visível de itens, tenho que pressionar duas vezes a seta para baixo para focar no próximo item.
• Quando pressiono ENTER para selecionar um item, o foco não é liberado. O comportamento esperado seria que o leitor de tela voltasse ao modo de navegação rápida e me deixasse ler o restante da página. Em vez disso, as teclas de seta ainda controlam minha escolha na lista.
• Os scripts atuais não permitem saber se as propostas são apresentadas e quantas são. Nos plugins selecionados mais acessíveis que conheço, o JAWS / NVDA anuncia quantos resultados correspondem à string inserida na entrada de texto.
• Finalmente, tenho a impressão de que o JAWS não entende se a lista é colaborada ou expandida. Às vezes, depois de fazer uma escolha com ENTER e tentar ler o resto da página, o JAWS ainda lê as propostas mais recentes que foram exibidas.

Bons pontos:

• A parte de autocompletar funciona bem. Se eu inserir "fra", o JAWS pronuncia "França" e posso pressionar ENTER para selecionar.
• Os itens são lidos corretamente conforme seta na lista.

Infelizmente não sei muitas coisas a respeito de ARIA, JavaScript e web em geral. Eu sugiro que você certifique-se de que o máximo de propriedades ARIA estejam adequadamente configuradas e atualizadas.

Veja abaixo a demonstração e o código de um plugin JQuery que interage perfeitamente com leitores de tela:
https://a11y.nicolas-hoffmann.net/autocomplete-list/

Lamento não poder ajudar mais.

Não hesite em postar novas demonstrações de seu trabalho. Estou feliz em testar para você.