Acessibilidade para plataforma móvel

Este documento contém uma lista concisa de requisitos para desenvolvedores de aplicativos móveis. Tem como intenção evoluir continuamente conforme forem aparecendo outros padrões.

Cor

  • O constrate de cor DEVE seguir os requirementos level AA do WCAG 2.0:
    • Razão de contraste de 4.5:1 para textos normais (com menos de 18 pontos e 14 pontos em negrito.)
    • Razão de contraste de  3:1 para textos grandes (com pelo menos 18 pontos ou 14 pontos em negrito.)
  • A informação transportada via cor DEVE ser também possível através de outros meios (textos sublinhados para links, etc.)

   Jon Snook escreveu um útil Colour Contrast Checker  que é usado para checar o contraste de cores entre o background e o foreground. De maneira alternativa o Tanaguru Contrast-Finder faz um trabalho similar, mas também sugeste melhores contrastes de cores considerando as usadas.

Visibilidade

  • Técnicas de esconder conteúdo como zero opacidade, ordem z-index e off-screen placement NÃO DEVEM ser exclusivas para visibilidade de manuseio.
  • Tudo que não é visível na tela DEVE ser verdadeiramente invisível (especialme relevante para apps de páginas únicas com múltiplos cards): 
    • USE o atributo hidden ou propriedades de estilo visibility ou display.
    • A não ser que seja extemamente inevitável, NÃO USE o atributo aria-hidden.

Foco

  • Todos os elementos em foco DEVEM:
    • Estar no padrão como os links, botões, e campo de formulário que são focalizados por padrão.
    • Controles não padrões DEVEM ter um ARIA Role apropriado para eles, como em button, link, ou checkbox.
  • O Foco deve ser utilizado com uma ordem lógica e consistente.

Textos Equivalentes

  • Textos equivalentes DEVEM ser declarados para cada elemento dentro do aplicativo que não sejam textos e aos elementos que não são estritamente presentacionais.
    • Use alt e title quando apropriado (veja a postagem de Steve Faulkner Using the HTML title attribute para uma boa referência.)
    • Se os atributos acima não forem aplicáveis, use os ARIA Properties apropriados, como aria-label, aria-labelledby, ou aria-describedby.
  • Imagens de textos DEVEM ser evitadas.
  • Todos controles de formulários DEVEM ter etiquetas (<label> elements) para melhor benefício dos leitores da tela.

Manipulação de Estado

  • Controles padrão como botões de rádio e checkboxes são manipuláveis pelo sistema operacional. No entanto, para uso customizado pode-se modificar esses estados via ARIA States como os aria-checked, aria-disabled, aria-selected, aria-expanded, e aria-pressed.

Orientações gerais

  • O título do aplicativo DEVE ser fornecido.
  • Cabeçalhos NÃO DEVEM ter sua hierarquia quebrada:
    <h1>Heading primeiro nível</h1>
      <h2>Heading segundo nível</h2>
      <h2>Outro Heading segundo nível</h2>
        <h3>Heading terceiro nível</h3>
  • ARIA Landmark Roles DEVE ser usado para descrever o aplicativo ou a estrutura do documento, como: banner, complementary, contentinfo, main, navigation, search.
  • Eventos de toque só DEVEM ser ativados no evento touchend.
  • Alvos tocáveis DEVEM ser largos o suficiente para o usuário interagir (veja o  BBC Mobile Accessibility Guidelines para ver as guidelines sobre tamanhos de alvos tocáveis .)

Tanaguru's automated accessibility testing service fornece uma maneira útil para descobrir alguns erros de acessibilidade que ocorrem em páginas web, ou instalando aplicativos web (ex: Firefox OS.) Você pode encontrar mais sobre a técnica de implementação do Tanaguru, como também contribuir para o projeto tanaguru.org.

 

Etiquetas do documento e colaboradores

 Colaboradores desta página: nathaliabruno, takahan
 Última atualização por: nathaliabruno,