Aplicativos modernos

Artigo
04/07/2015

Criar e desenvolver aplicativos modernos acessíveis

Rachel Appel Qual é o valor da tecnologia — a Internet, aplicativos e várias formas de mídia — a menos que haja um humano benefício? Infelizmente, há muito software por aí que não beneficia as pessoas. Designers, gerentes e os desenvolvedores geralmente têm mais atenção à segurança e ao desempenho do que à acessibilidade. A acessibilidade é geralmente uma baixa prioridade no software, se for uma prioridade.

A acessibilidade deve ser uma prioridade alta. O WebAIM estima que 20 por cento dos usuários da Web têm necessidades de acessibilidade ou confiam nas tecnologias assistenciais. Isso é mais de 60 milhões de pessoas apenas nos Estados Unidos que podem ter dificuldade em usar seu site ou aplicativo ou consumir o conteúdo. Para a maioria dos aplicativos e sites da Web, a perda de clientes corresponde diretamente na perda de receita. Meu PDF, "A importância da acessibilidade" ilustra muitas outras razões para um design acessível (baixe em bit.ly/1CIx4k4).

O ABC da acessibilidade

Ao projetar e desenvolver com acessibilidade em mente, considere as amplas categorias de deficiência:

Visual: Pessoas com deficiência visual variam de baixa visão à cegueira, incluindo um espectro de deficiências de cor.
Audição: Pessoas com deficiência auditiva podem ser totalmente surdas ou ter dificuldade para ouvir.
Motora: Há muitas pessoas com deficiências motoras. Algumas sofreram perda completa ou o uso dos membros. Outros poderão não ter neuropatia de um acidente ou doença. Pessoas com deficiência motora podem precisar de dispositivos de entrada especializados.
Cognitiva: Pessoas com deficiências de aprendizado, incluindo ADHD e dislexia, frequentemente têm dificuldade de consumir informações, dependendo de sua apresentação.

Muitas pessoas exigem alguma forma de tecnologia assistencial. Tecnologia assistencial é qualquer ferramenta ou tecnologia usada para ajudá-lo nas atividades diárias para torná-as mais fáceis ou possíveis. Pessoas raramente consideram que óculos seja uma tecnologia assistencial, mas são — embora na extremidade inferior da escala de tecnologia. Alguns usuários de tecnologia não podem viver sem seus óculos. Tecnologias assistenciais comuns incluem leitores de braille, cartões de boca, varinhas de cabeça, teclados adaptáveis, software de reconhecimento de voz e assim por diante.

Design e conteúdo acessível

Você descobrirá que o design mais acessível geralmente é considerado um ótimo design. Muitos sites da Web têm muitos anúncios obstruídos no fluxo de conteúdo, o que interromperá bastante fluxo do leitor. Outros têm menus e aspectos de navegação difíceis de usar. O layout e a navegação de um site ou aplicativo da Web são considerações importantes em relação às necessidades de acessibilidade.

Ao organizar o conteúdo, separe-o em seções distintas com cabeçalhos claros. Filmes, músicas e animações devem incluir legendas ou transcrições como parte de seu conteúdo. A maioria dos software de criação de filmes disponível hoje permite inserir transcrições de legenda codificada.

Um bom design também significa um esquema de navegação claro e consistente. Menus em cascata JavaScript são muitas vezes difíceis para usuários sem deficiência. Eles são piores para portadores de deficiência motora. Links na parte superior ou inferior de uma página da Web funcionam melhor. Em aplicativos de telefone, você desejará acompanhar o esquema de navegação do dispositivo de destino. Para obter mais informações sobre navegação no Windows 8.x, consulte minha coluna de agosto de 2013, "Fundamentos da navegação em aplicativos da Windows Store" (msdn.microsoft.com/magazine/dn342878).

Fontes devem ser grandes e claras. Fontes de script são mais difíceis de ler. Há muitas coisas que podem tornar algumas letras de uma fonte não claras. Uma é a dislexia, que causa uma incapacidade de distinguir entre letras que se parecem. Uma estimativa de 5% da população tem dislexia. Letras que são direcionadas para não disléxicos parecem invertidas e de trás para frente para os disléxicos.

Usando esse conhecimento sobre dislexia, as pessoas em dyslexiefont.com criaram uma fonte que muda letras levemente para que elas sejam mais fáceis de ler. Até agora, os testadores de fonte adoraram. Você pode optar por não usar dyslexiefont e tudo bem. Isso não significa que você está esnobando a dislexia. No entanto, certifique-se de escolher uma fonte que seja tão fácil de ler.

Você talvez queira repensar a mudança da fonte se seu aplicativo for orientado para empreendimentos. As cores de fonte também devem ter alto contraste. Um bom exemplo de alto contraste é um plano de fundo claro ou branco com texto preto ou escuro. O completo oposto também é verdadeiro. Usar texto claro em planos de fundo escuros também funciona. Geralmente é uma questão de preferência e estilo de qual usar, desde que haja contraste suficiente.

Você não pode errar com uma estratégia de design de dispositivos móveis. Designs móveis geralmente forçam você a fazer o melhor uso possível de espaço. A maioria dos telefones e tablets pequenos têm apenas algumas polegadas de espaço para o conteúdo. Isso significa que o aplicativo geralmente apresenta apenas as informações mais importantes. Nesse cenário, simplesmente não há nenhum espaço para anúncios verticais.

Há outras práticas de bom design que você pode seguir que também ajudam a garantir a acessibilidade. Pense em sites de notícias e sites sociais mais populares na Web. Muitos delas não estão acessíveis ou são acessíveis apenas a um pequeno grau. Eles geralmente contêm pop-ups que atrapalham e podem interromper completamente os leitores de tela e humanos. Esses mesmos pop-ups geralmente têm botões de fechamento pequenos que são difíceis de encontrar e impossíveis de clicar ou tocar — até mesmo com dispositivos principais.

Outros utilizam pop-ups seriais. Quando você finalmente se livra de um pop-up; outro toma seu lugar. Isso é frustrante. Muitas pessoas com necessidades de acessibilidade se recusam a visitar esses sites, porque simplesmente que vale a pena o trabalho.

Evite efeitos de estroboscópio, efeitos piscantes ou imagens piscando sem aviso. Isso representa um risco de convulsão. Além disso, eles geralmente são irritantes, a menos que sejam especificamente uma ilusão ótica ou truque de olho.

Não use apenas cores para transmitir sua mensagem aos usuários. Por exemplo, muitas formas usam uma fonte vermelha para indicar um campo obrigatório. Pessoas daltônicas não podem ver a diferença. Não basta usar a frase "clique aqui" como texto de link. Isso não ajuda os leitores de tela. Use algo descritivo.

Código de programa acessível

Há técnicas de programação que podem ser usadas para desenvolver aplicativos e sites da Web acessíveis. Como desenvolvedor, você precisa interagir com a entrada e saída. Isso significa que você deve ter em mente que diferentes pessoas precisam de diferentes maneiras de interagir com o software e não apenas o mouse e teclado.

Para aqueles que usam os principalmente ou exclusivamente o teclado, certifique-se de que as ordens das guias de campo sejam simples e estejam na ordem. Você também deverá rotular campos e elementos como botões usando o elemento HTML <label>. Isso garante maior clareza. Imagens devem ter atributos alt definidos como algo descritivo, mas sucintos. Leitores de tela não podem ler magicamente imagens, portanto, eles usam a marca alt para descrever a imagem para o ouvinte.

HTML5 contém um conjunto de elementos chamado elementos semânticos. O ponto deles é para que máquinas e humanos possam facilmente ler e entender os elementos HTML. Elementos semânticos descrevem seu conteúdo como XML. Por exemplo, qualquer pessoa pode entender os seguintes elementos semânticos apenas através da leitura: legenda, figura, artigo, rodapé, cabeçalho, resumo, hora, nav, marcação e principal, para citar alguns.

Para aqueles que dependem de um leitor de tela, links de pulo são salvadores. Um link de pulo permite que um leitor passe por elementos de navegação e anúncios em um site da Web e vá diretamente para o conteúdo desejado. Precisar passar por várias iterações de opções e anúncios desnecessários e cansativos não é divertido. Não force os usuários a passar por essa dura experiência. Imediatamente após o elemento <body> é onde entra o link de navegação pular principal, conforme mostrado no código a seguir:

<body>
<a href="#maincontent">Skip to main content</a>
<nav><!-- navigation here --></nav>
<main id="maincontent">
<p>The quick brown fox jumps over the lazy dog.</p>

Quando o leitor de tela ver o link de pular, ele se concentra no elemento que link de pular se refere a pela sua id. Isso significa que no exemplo anterior, esse link de pular aponta para o elemento <main> com a id "maincontent". Como os links de pular devem ser os primeiros elementos e muitos designers preferem que o link de pular fique em outro lugar, você pode ocultá-lo e torná-lo visível para tecnologia assistencial com CSS, conforme mostrado neste código:

.skiplink-offscreen {
  position:absolute;
  left:-10000px;
  top:auto;
  width:1px;
  height:1px;
  overflow:hidden;
}

Como você pode ver, é um seletor de classe de posicionamento absoluto com um atributo de valor definido como - 10000px. O estouro permanece oculto. O código está posicionando o elemento que usa esse seletor onde o usuário nunca o verá, mas um leitor de tela sim. Leitores de tela ignoram elementos com atributos ocultos ou exibidos definidos como oculto ou nenhum. É por isso que você deve usar esse pequeno atalho.

Desenvolver com ARIA

Accessible Rich Internet Applications (ARIA) é um conjunto de atributos padrão que você pode aplicar para marcação como HTML que auxilia a tecnologia assistencial a funcionar corretamente. Com o ARIA, você pode definir um elemento por seu estado, propriedade ou função. Dessas informações, os leitores de tela podem determinar que o software está fazendo.

Por exemplo, uma caixa de seleção pode ter um estado de ARIA marcado. Ou um elemento pode assumir a função de um menu. Esse bit de informações adicionais sobre a função ou o estado ajuda os leitores de tela a construir uma melhor representação do conteúdo da página da Web. Esses atributos não alteram o elemento, mas fazem com que o elemento se comporte em uma forma mais semântica. A marcação semântica é mais fácil para seres humanos e máquinas entenderem. Por exemplo, o código a seguir mostra um artigo com uma seção que é semântica, para que um leitor de tela possa identificar melhor o conteúdo relacionado e transmiti-lo ao usuário:

<article>
<section aria-labelledby="ProgrammingBestPractices">
  <h2 id="ProgrammingBestPractices">Best Practices for Programmers</h2>
  <ol>
  <li>Take a few minutes a day to refactor small portions of code.</li>
  <li>Learn a new programming language every year.</li>
  </ol>
</section>
</article>

Você pode estender essa marcação semântica e acessível em formulários HTML. Leitores de tela precisam saber que elementos rotulam ou descrevem campos de formulário e quais campos são pertencentes a um grupo. O estado dos botões e das caixas de seleção é outra coisa sobre a qual os leitores de tela devem saber. O bom design do formulário significa conhecer como script afeta a tecnologia assistencial. Você pode reconsiderar o código que define automaticamente o foco para um controle ou altera dinamicamente o estado dos controles de formulário.

Use o elemento HTML <label> para rotular elementos de formulário individuais para rótulos único. No entanto, haverá momentos em que você precisa rotular um elemento com vários rótulos, como em uma tabela. Não tem problema. O atributo aria-labelledby funciona nesses casos. Defina aria-labelledby de cada elemento no grupo para as ids de elemento que fará a rotulagem. Você pode usar o elemento <rótulo> e o atributo aria-labelledby no mesmo formulário. Não é necessário rotular os botões Enviar ou Redefinir, a menos que sejam botões de imagem. Em seguida, certifique-se de definir o atributo alt.

Cada formulário exigiu elementos e elementos com restrições específicas do tipo de dados que ele aceitará. A maioria dos formulários executa um JavaScript para realizar a validação em campos obrigatórios e restritos. Eles fazem isso antes de enviar todos os dados de volta para o servidor para processamento, porque é melhor notificar o usuário de erros o mais cedo possível. Leitores de tela têm dificuldade para diferenciar o que está acontecendo na página quando um script é executado. Para solucionar esse problema, use os atributos aria-required e aria-invalid, conforme mostrado na Figura 1.

Figura 1 Formulário HTML acessível com atributos ARIA

<form>     
  <div>
    <label for="name">* Name:</label>
    <input type="text" id="name" aria-required="true" />
  </div>
  <div>
    <label for="checkboxGroupLabel">* Language</span>
    <ul role="radiogroup" aria-labelledby="checkboxGLabel">
      <li role="checkbox"><input type="checkbox" value="C#"
        name="language" aria-checked="false" />C#</li>
      <li role="checkbox"><input type="checkbox" value="JavaScript"
        name="language" aria-checked="false" />JavaScript</li>
      <li role="checkbox"><input type="checkbox" value="Python"
        name="language" aria-checked="false" />Python</li>
    </ul>
  </div>
  <div>
    <span id="yearsLabel">* Years Experience</span>
    <select name="YearsExperience" aria-labelledby="yearsLabel" >
      <option value="1">1-5 Years</option>
      <option value="6">6-10 Years</option>
      <option value="10">10-20 Years</option>
      <option value="20">20+ Years</option>
    </select>
  </div>
  <div>
    <input type="submit" alt="Submit" />
  </div>
</form>

Também mostrado na Figura 1 está um exemplo de aria-required e aria-labelledby e de como usar funções. Você está apenas adicionando algum HTML extra, mas não invasivo. Ele não exige muito esforço e fornece um grande retorno.

A tecnologia assistencial deve lidar com mais do que elementos estáticos. Chamadas de JavaScript, AJAX e aplicativos de estilo SPA frequentemente alteram o conteúdo de sites e aplicativos. Às vezes um script dinâmico como esse é obtido diretamente na forma de leitores de tela. Você deve redefinir o estado de alguns atributos ARIA, como aria-invalid, após a execução de validação do JavaScript.

Testar o código acessível

Teste seu trabalho baixando o software de leitura de tela e experimentando tecnologias assistenciais por conta própria. Feche os olhos e use o leitor de tela, como se estivesse cego. Obter comentários dos usuários que usam tecnologia assistencial também é uma ótima maneira de ver quão acessível é o software que você criou. Você pode baixar alguns leitores de tela e usar:

NVDA: nvaccess.org
JAWS para Windows: bit.ly/1yJkxuV
Window-eyes: gwmicro.com
VoiceOver para OS X: bit.ly/1JuA1q9

Quando tiver testado para leitores, WebAIM tem um scanner de lista de verificação e página abrangente chamado ferramenta Avaliação de Acessibilidade da Web (WAVE de forma abreviada), que irá relatar erros, avisos e outras informações sobre o status de acessibilidade de uma página. É simples de usar. Vá para wave.webaim.org e digite a URL que você deseja verificar. WAVE exibe a página de destino embutida e anota spots e elementos problemáticos que podem ser alterados para melhorar a acessibilidade. A Figura 2 mostra o scanner em ação, como ele sinaliza alguns itens na página de edição da MSDN Magazine de janeiro de 2015.

MSDN Magazine Após a execução com o Scanner WAVE
Figura 2 MSDN Magazine Após a execução com o Scanner WAVE

Clique em qualquer um dos elementos anotados e o WAVE exibirá informações de erro ou metadados sobre o elemento. O scanner olha tudo, desde a falta de rótulos e atributos alt a problemas de contraste. Ele os sinaliza como erros ou avisos para que você possa alterar os problemas mais importantes primeiro. Você pode executar uma versão autônoma do WAVE ou pode adicionar a API a seus processos de controle de qualidade automáticos.

Conclusão

Design acessível geralmente é uma abordagem de design melhor para todos. Um design não acessível perde erros em uma porcentagem significativa da população, portanto, é simplesmente uma boa decisão de negócios colocar esforços para tornar seu software acessível. Interfaces do usuário devem apresentar opções claramente rotuladas, fáceis de localizar e criar etapas para concluir uma tarefa de forma simples e direta. Quando você cria para acessibilidade, você obtém automaticamente um sistema simples e fácil de usar que funciona bem para todos.

Rachel Appel é consultora, autora, mentora e antiga funcionária da Microsoft com mais de 20 anos de experiência no setor de TI. Ela dá palestras em importantes congressos do setor, como o Visual Studio Live!, o DevConnections, o Mix e muitos outros. Sua experiência está ligada a soluções de desenvolvimento que alinham negócios e tecnologia com foco na pilha de desenvolvimento da Microsoft e em Web aberta. Para obter mais informações sobre a Appel, visite seu site em rachelappel.com.

Agradecemos ao seguinte especialista técnico da Microsoft pela revisão deste artigo: Frank La Vigne