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

**Nota:** 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:

```html
<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 .)

**Nota:** 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.

**Nota:** A versão original desse documento foi escrita por Yura Zenevich.