Lista de verificação em branco, formulário para impressão
Lista de acessibilidade de aplicações móveis
Capítulo 11 da EN 301 549 + WCAG 2.2 AA para aplicações móveis nativas
Lista de verificação em branco para preenchimento offline.
Marque uma caixa por linha. Adicione comentários e referências de prova na coluna Notas conforme necessário.
Compatibilidade com leitor de ecrã
EN 301 549 §11.1.1–§11.4, todos os elementos de UI têm de ser acessíveis aos leitores de ecrã da plataforma (TalkBack, VoiceOver).
| Ref | Gravidade | Requisito | Estado | Notas / Provas |
|---|---|---|---|---|
| EN 301 549 §11.5.2.3 | Crítico | Todos os elementos interativos têm nomes acessíveis expostos à API de acessibilidade da plataforma.Cada botão, ligação, campo e controlo tem de ter um nome programático, via contentDescription (Android), accessibilityLabel (iOS) ou texto visível. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D | |
| EN 301 549 §11.5.2.5 | Crítico | Todos os elementos interativos expõem o seu papel à tecnologia de apoio.Os botões têm de ser anunciados como botões, as caixas de verificação como caixas de verificação, as ligações como ligações. Utilize controlos nativos da plataforma ou defina accessibilityRole explicitamente. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D | |
| EN 301 549 §11.5.2.7 | Crítico | As alterações de estado (expandido, selecionado, marcado) são expostas programaticamente.Quando um alternador muda, uma lista pendente expande ou um separador é selecionado, o leitor de ecrã tem de anunciar o novo estado automaticamente. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D | |
| EN 301 549 §11.5.2.12 | Importante | O foco segue uma ordem de leitura lógica correspondente ao esquema visual.A navegação por deslize do leitor de ecrã tem de percorrer os elementos numa ordem lógica, de cima para baixo, da esquerda para a direita. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D |
Entrada e gestos
EN 301 549 §11.1.2, os gestos táteis, métodos de entrada e controlo por teclado/comutador têm de ser acessíveis.
| Ref | Gravidade | Requisito | Estado | Notas / Provas |
|---|---|---|---|---|
| WCAG 2.5.1 | Crítico | Cada gesto de deslize, beliscar ou multitoque tem uma alternativa de um único toque ou botão.O beliscar para ampliar tem de ter botões +/-. O deslizar para eliminar tem de ter um botão Eliminar explícito. Nenhuma funcionalidade deve exigir exclusivamente gestos complexos. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D | |
| WCAG 2.5.8 | Crítico | As áreas de toque cumprem o tamanho mínimo de 44×44 pt (iOS) / 48×48 dp (Android).Botões pequenos causam falhas de acessibilidade motora. Meça o tamanho renderizado em dispositivos reais. O preenchimento conta para a área de toque. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D | |
| WCAG 2.1.1 | Crítico | A navegação completa por teclado e controlo por comutador funciona em todos os fluxos.Os utilizadores de teclado externo e de controlo por comutador têm de poder concluir todas as tarefas. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D | |
| WCAG 2.5.4 | Importante | Nenhuma funcionalidade depende de movimento do dispositivo (inclinar, agitar) sem alternativa.O «agitar para desfazer» tem de ter uma alternativa no menu. O «inclinar para rolar» tem de ter controlos por botão. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D | |
| EN 301 549 §11.7 | Importante | A aplicação respeita as preferências de acessibilidade da plataforma (texto a negrito, reduzir movimento, aumentar contraste).Quando o SO tem «Reduzir movimento» ativado, a aplicação tem de reduzir ou remover animações. «Texto a negrito» deve afetar a tipografia da aplicação. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D |
Acessibilidade visual
WCAG 1.3–1.4 aplicada à UI móvel nativa, contraste de cor, redimensionamento de texto, orientação.
| Ref | Gravidade | Requisito | Estado | Notas / Provas |
|---|---|---|---|---|
| WCAG 1.4.3 | Crítico | O contraste de cor do texto cumpre o rácio de 4,5:1 (3:1 para texto grande).Meça contra todos os fundos, incluindo gradientes e imagens. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D | |
| WCAG 1.4.11 | Importante | Os componentes de UI não textuais (ícones, bordas, aros de foco) cumprem 3:1 de contraste.As bordas de botão, os contornos de campo, os gráficos de ícone, todos têm de ter contraste suficiente com o fundo. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D | |
| WCAG 1.4.4 | Crítico | O texto redimensiona até 200% através das definições do sistema sem perda de conteúdo.Ative a escala de tipo do sistema e verifique se todo o texto escala corretamente. Sem truncagem, sobreposição ou conteúdo oculto por transbordamento. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D | |
| WCAG 1.3.4 | Importante | A aplicação funciona em retrato e paisagem, exceto se uma orientação for essencial.O conteúdo deve remodelar para ambas as orientações. Só fixe a orientação se o conteúdo o exigir genuinamente. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D | |
| WCAG 1.4.1 | Crítico | A cor não é o único meio de transmitir informação.Os estados de erro, indicadores de estado e estados selecionados têm de usar forma, texto ou ícones além da cor. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D |
Notificações e feedback
Alertas, vibração e notificações do sistema têm de ser acessíveis por múltiplos canais sensoriais.
| Ref | Gravidade | Requisito | Estado | Notas / Provas |
|---|---|---|---|---|
| EN 301 549 §5.1.3.1 | Crítico | As notificações estão disponíveis em forma de texto, não apenas som ou vibração.As notificações push têm de incluir texto legível. Alertas apenas hápticos ou apenas áudio excluem utilizadores surdos e surdocegos. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D | |
| EN 301 549 §5.1.3.1 | Importante | O feedback háptico tem alternativa não háptica.Utilizadores que não conseguem perceber vibração precisam de confirmação visual ou sonora para eventos hápticos. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D | |
| WCAG 4.1.3 | Importante | As mensagens de estado são anunciadas pelo leitor de ecrã sem mudança de foco.Mensagens toast, indicadores de carregamento e confirmações de submissão de formulário têm de utilizar os anúncios de acessibilidade da plataforma. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D |
Autenticação e sessões
Início de sessão, biometria, tempos limite e gestão de sessão têm de ser acessíveis.
| Ref | Gravidade | Requisito | Estado | Notas / Provas |
|---|---|---|---|---|
| EN 301 549 §5.3 | Crítico | O início de sessão biométrico (impressão digital, face) tem alternativa PIN/palavra-passe.Nem todos os utilizadores podem usar biometria. Tem de existir sempre um caminho não biométrico. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D | |
| WCAG 2.2.1 | Importante | Os tempos limite de sessão avisam o utilizador e permitem prolongamento.Mostre um aviso pelo menos 20 segundos antes do término. Permita ao utilizador prolongar. Não termine a sessão silenciosamente. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D | |
| WCAG 3.3.8 | Importante | A autenticação não exige testes de função cognitiva (CAPTCHAs) sem alternativa acessível.CAPTCHAs são barreiras para muitos utilizadores. Use métodos de verificação alternativos. | ☐ Aprovado ☐ Parcial ☐ REPROVADO ☐ N/D |