Yahoo! Blog User Interface (YUIBlog)

Fazendo Pesquisa Directa Acessível

8 de agosto de 2011 às 09:44 por Caridy Patino | Em Acessibilidade e Desenvolvimento | 6 Comentários

Alguns meses atrás nós lançamos a primeira versão beta da busca direta. Este novo produto explora o conceito de feedback em tempo real, de imediato, oferecendo respostas para o usuário com cada tecla. Dada a diversidade de audiência do Yahoo!, nós queríamos fazer Busca Direta tão acessíveis quanto possível. Inicialmente, acreditávamos que isso seria uma tarefa fácil, já que este produto seria baseado no YUI 3, uma biblioteca JavaScript com acessibilidade cozido em seu DNA. Contrariamente às minhas expectativas como um engenheiro, essa tarefa acabou por ser mais difícil do que prevíamos.

Apresentando Pesquisa Directa

Apesar de Pesquisa Directa é construído a partir do zero usando infra-estrutura YUI componente, sua interface mais visível proeminente é baseado no widget AutoComplete YUI que inclui vários recursos de acessibilidade para a direita fora da caixa. Sugestões relacionadas com uma determinada consulta são exibidos nesta implementação autocomplete. Busca Direta também apresenta um painel de conteúdo, também conhecido como o painel rico, onde o conteúdo relacionado sugestão é exibida. A intenção do painel de rico é dar uma resposta direta para o usuário quando uma sugestão da lista de preenchimento automático está selecionado.

Um novo conjunto de sugestões é exibida na lista em todas as teclas, ea primeira sugestão é selecionada por padrão. Esta seleção padrão é chamado de uma seleção suave. Seleções suaves e interações subsequentes com a lista de sugestões ditar o conteúdo que é apresentado no painel de rico. Na realidade, as coisas são um pouco mais complicado (otimizações de desempenho, camadas adicionais de cache, etc), mas por uma questão de simplicidade, podemos supor que este é o fluxo de trabalho comum.

Os recursos de acessibilidade

Na busca para fazer pesquisa direta acessível, nós olhamos para a implementação de Assistente de Pesquisa, uma tecnologia que foi pioneira Yahoo! alguns anos atrás, bem como os recursos de acessibilidade nativas da YUI.

Após esta investigação, três recursos de acessibilidade primários foram propostos para pesquisa direta:

• Usando o utilitário Internacionalização YUI para servir conteúdo localizado.
• Definir role e aria-* atributos em elementos dentro do widget autocomplete, que precisam ser identificados e processados ​​por leitores de tela.
• Usando um oculto div que representa uma região ao vivo ( aria-live ) para notificar o usuário quando algo acontece. Por exemplo, o número de sugestões disponíveis, a sugestão seleccionado, etc

O plano era para notificar o usuário de quaisquer alterações na interface de busca direta, e fornecer um conjunto de atalhos de teclado para navegar os seguintes componentes visuais:

• Caixa de pesquisa
• Botão Enviar
• Lista de sugestões
• Rico painel

Soa como uma brisa, certo? Bem, vamos dar um passo atrás.

O problema

O que temos aqui são dois processos assíncronos - um deles para atualizar o conjunto de sugestão e outro para recuperar respostas correspondentes - e ambos estão realmente rápido. Estamos falando de final 250ms para terminar. Uma vez que a interface está mudando em um ritmo tão rápido, mantendo o controle de tudo pode ser difícil para um usuário de leitor de tela. Ela recebe uma ordem de magnitude mais complicado quando as atualizações acontecem em um assíncrono, quase em tempo real forma. Como o leitor de tela estava sendo notificado de todas as alterações na interface, a vibração resultante tornou difícil entender o que estava acontecendo.

Na falta de uma solução aceitável, começamos a colaborar com Yahoo! 's guru acessibilidade, residente Victor Tsaran ( @ vick08 ) para tentar chegar a algo melhor.

A primeira vez que assistiu Victor interagir com Procura Directa, ficou imediatamente claro para mim que a maioria de seu foco estava no painel rico em vez da lista de sugestões. Isso foi uma surpresa para mim, como visto na lista como a "fonte da verdade". Durante uma de nossas sessões, tivemos um golpe de sorte, quando aconteceu a desativar todos os recursos de acessibilidade da lista. Assim como o ruído introduzido pela lista foi cortada, a busca direta começou a fazer sentido para Victor!

Como os usuários de leitores de tela perceber Busca Direta

Depois de perceber que nós estávamos tentando resolver o problema errado, voltamos para a história do usuário original: "Como usuário, eu posso obter uma resposta como eu digito". Obtendo a resposta para o usuário através era a prioridade. Depois de redefinir o problema, nós nos concentramos nossos esforços de acessibilidade em uma aplicação onde o leitor de tela priorizado o conteúdo rico painel sobre a lista de sugestões.

Por exemplo, se o usuário digita "miami wea" , o leitor de tela irá dizer-lhes duas coisas:

• 10 sugestões.
• TEMPO MIAMI, FL. HOJE, Parcialmente Nublado, 89 ° F 77 ° F. AMANHÃ, Parcialmente Nublado, 90 ° F 74 ° F ...

Será, então, continue lendo o resto do conteúdo do painel rico. O usuário não precisa saber todas as 10 sugestões na frente, toda vez que as atualizações da lista. Se eles não querem saber, a informação é facilmente acessível via navegação do teclado.

Para garantir que a lista de sugestões é agregar valor à experiência, temos certeza de que a primeira frase no painel rico está intimamente relacionado com a sua sugestão correspondente. Por exemplo, com base no exemplo anterior, "weather miami" é a primeira frase no painel rico para a sugestão: "weather miami".

Victor Tsaran, do Laboratório de Acessibilidade Yahoo!, mostra como ele funciona no FireFox com o ecrã NVDA leitor:

A experiência de leitor de tela para a nossa aplicação é mais fácil de seguir, já que agora apenas se concentrar nas duas seguintes componentes visuais:

• Caixa de pesquisa
• Rico painel

As alterações à lista autocomplete como um todo não são mais controladas, eo botão de submit é ignorado, pois o usuário sempre pode bater entrar para a consulta atual ou usar um atalho de teclado (tecla de acesso tilda: [control, alt or shift] + ~ ) para alternar entre o elemento de entrada e do painel de rico. Estas opções de navegação do teclado são revelados para o usuário quando o searchbox é reconhecido pelo leitor de tela.

Do ponto de vista de engenharia, esta mudança simplificou as coisas. A quantidade de manipulação DOM no componente mais ativo foi drasticamente reduzida, melhorando o desempenho geral de Pesquisa Directa. Aqui é um exemplo da aplicação:

 SDAAria função () {
     var node = this._liveRegion = Y.Node.create ('<div role="status" class="off-screen" aria-live="assertive"> </ div>');
     / / Cria a região ARIA ao vivo ...
     Y.one ('body') append (nó).;
     / / Ouvindo ária: mensagens ao vivo para atualizar a região ao vivo
     this.on ('aria: ao vivo ", this._handlerMsg, this);
     / / Para ouvir fofocas: atualização para anunciar quantas sugestões
     this.on ('fofoca: refresh', this._handleGossipRefresh, this);
 }
 SDAAria.ATTRS = {
      strings: {
          valueFn: function () {
              voltar Y.Intl.get ('sd-aria');
          }
      }
 };
 SDAAria.prototype = {
     _ariaSay: function (stringID, subs) {
         var mensagem = this.get ("strings". + stringID) | |'';
         this._liveRegion.setContent (? subs Y.Lang.sub (mensagem, subs): message);
     },
     _handlerMsg: function (e) {
         if (e.id) {
             this._ariaSay (e.id, e.subs);
         }
     },
     _handleGossipRefresh: function () {
         var tamanho = this.get ('sugestões') size ().;
         this._ariaSay (tamanho (> 0 "sugestões:? dos NO_SUGGESTIONS '), {
             n: tamanho
         });
     }
 };

As lições aprendidas

Ao criar uma interface acessível, é importante fazer as perguntas certas. Fazendo cada bit do seu aplicativo acessível não pode ser a abordagem certa.

Solicite feedback inicial dos usuários de leitores de tela - não assuma que você tem suas bases cobertas até que você obter algum feedback do usuário. Utilizando todas as ferramentas e recursos à sua disposição não pode ter o efeito pretendido.

Usuários de leitores de tela podem ter dificuldade em manter o controle de atualizações em tempo real, especialmente se os leitores de tela são bombardeados com as notificações. Nesses cenários, menos pode significar mais. Identificar e focar no que é importante para o usuário ao invés de tentar replicar a experiência crua do pedido de leitor de tela.

Sobre o autor: Caridy Patiño, Frontend principal para Yahoo! Search Direct. Ele tem sido um colaborador de longa data YUI e criador da borbulhagem Biblioteca de Extensão YUI, bem como blogueiro convidado no YUIBlog.com compartilhar alguns de sua extensa experiência construção de aplicações web de alta performance. Estratégias de carga, event-driven arquitecturas e SSJS são alguns dos temas em Caridy passa a maior parte do seu tempo nestes dias.

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark com del.icio.us | digg it! | reddit!