Lista de verificação em branco, formulário para impressão

Grelha de Testes de Interoperabilidade com Tecnologias Assistivas

Grelha de Compatibilidade EN 301 549 §5.1 + §11.5

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.

Leitores de ecrã, multiplataforma

Verificar a compatibilidade com os principais leitores de ecrã em todas as plataformas, Windows, macOS, iOS e Android.

RefGravidadeRequisitoEstadoNotas / Provas
EN 301 549 §11.5.2CríticoTestado com NVDA no Windows.O NVDA é o leitor de ecrã gratuito mais utilizado no Windows. Teste todos os percursos centrais, navegação, formulários, componentes interativos e conteúdo dinâmico. O NVDA usa o buffer virtual e os modos browse/focus; verifique que ambos funcionam com a sua interface.Aprovado
Parcial
REPROVADO
N/D
 
EN 301 549 §11.5.2CríticoTestado com JAWS no Windows.O JAWS é o leitor de ecrã comercial mais utilizado em ambientes empresariais. O modelo de interação difere do NVDA em áreas chave, comportamento do cursor virtual, ativação do modo de formulários e definições de verbosidade. Teste em separado mesmo que o NVDA passe.Aprovado
Parcial
REPROVADO
N/D
 
EN 301 549 §11.5.2CríticoTestado com VoiceOver em macOS e iOS.O VoiceOver está integrado no macOS e iOS. Teste com Safari nas duas plataformas, pois oferece o melhor suporte a VoiceOver. Em iOS, teste navegação tátil (deslizar para a esquerda/direita) e gestos do rotor. O VoiceOver trata o ARIA de forma diferente dos leitores de ecrã do Windows em várias áreas.Aprovado
Parcial
REPROVADO
N/D
 
EN 301 549 §11.5.2CríticoTestado com TalkBack no Android.O TalkBack é o leitor de ecrã integrado no Android. Teste com o Chrome no Android, que tem o melhor suporte. Navegação por gestos de deslize (semelhante ao VoiceOver iOS). Atenção a vistas personalizadas, conteúdo WebView e tamanhos de alvo táctil.Aprovado
Parcial
REPROVADO
N/D
 

Ampliação de ecrã e baixa visão

Verificar a funcionalidade com zoom do navegador, lupas do sistema, modos de alto contraste e inversão de cores, crítico para utilizadores com baixa visão.

RefGravidadeRequisitoEstadoNotas / Provas
WCAG 1.4.4CríticoToda a funcionalidade funciona com 200% de zoom no navegador.O WCAG exige que o conteúdo seja funcional e legível a 200% de zoom. Não deve ser necessário deslocamento horizontal para conteúdo de deslocamento vertical. O texto tem de fluir em vez de ser cortado ou sobreposto. Todos os elementos interativos têm de continuar acessíveis.Aprovado
Parcial
REPROVADO
N/D
 
EN 301 549 §11.5.2ImportanteO conteúdo continua funcional com ZoomText ou lupa do sistema.O ZoomText (Windows) e as lupas integradas (Windows Magnifier, macOS Zoom) ampliam porções do ecrã. O conteúdo tem de continuar utilizável, dicas e popups têm de aparecer junto aos seus acionadores (não fora do ecrã) e os indicadores de foco têm de ser visíveis em alta ampliação.Aprovado
Parcial
REPROVADO
N/D
 
WCAG 1.4.11CríticoA interface é utilizável no modo de Alto Contraste do Windows e no aumento de contraste do macOS.Os modos de alto contraste substituem cores e podem remover imagens de fundo, gradientes e sombras. Elementos de UI que dependem destes tratamentos visuais podem tornar-se invisíveis. Use bordas transparentes e CSS forced-color-adjust onde necessário.Aprovado
Parcial
REPROVADO
N/D
 
WCAG 1.4.1ImportanteO conteúdo continua legível com cores invertidas.Alguns utilizadores com baixa visão invertem as cores para texto claro sobre fundo escuro. O conteúdo tem de permanecer legível e as imagens não devem tornar-se inutilizáveis. Evite transmitir informação só por cor, pois as relações de cor invertem-se.Aprovado
Parcial
REPROVADO
N/D
 

Entradas motoras e alternativas

Verificar a compatibilidade com acesso por comutador, controlo por voz, operação total por teclado e métodos de entrada por dwell/seguimento ocular.

RefGravidadeRequisitoEstadoNotas / Provas
EN 301 549 §5.1.3CríticoO acesso por comutador (Switch Control iOS / Switch Access Android) consegue navegar todas as funções.Os utilizadores de switch access navegam por varrimento sequencial e ativam com um ou dois comutadores. Todos os elementos interativos têm de ser alcançáveis pela ordem de varrimento. Componentes personalizados têm de ser focáveis e ativáveis. Agrupe elementos relacionados para reduzir o tempo de varrimento.Aprovado
Parcial
REPROVADO
N/D
 
EN 301 549 §5.1.3CríticoO controlo por voz (Dragon NaturallySpeaking / macOS Voice Control) consegue ativar todos os controlos.Os utilizadores de controlo por voz dizem o nome ou etiqueta visível do controlo para o ativar. Todos os elementos têm de ter etiquetas visíveis ou nomes acessíveis pronunciáveis. «Click Submeter» tem de funcionar para um botão etiquetado «Submeter». Controlos personalizados sem etiquetas visíveis ficam inutilizáveis.Aprovado
Parcial
REPROVADO
N/D
 
WCAG 2.1.1CríticoToda a funcionalidade é acessível por teclado sem exigir rato.Cada funcionalidade disponível por rato tem de estar igualmente disponível por teclado. Inclui navegação, preenchimento de formulários, alternativas a arrastar e largar, menus de contexto e dispensar sobreposições. O foco tem de estar sempre visível e seguir uma ordem lógica.Aprovado
Parcial
REPROVADO
N/D
 
WCAG 2.5.1ImportanteSem interações dependentes de hover, compatível com dwell e seguimento ocular.Os clicadores por dwell e os sistemas de seguimento ocular ativam elementos por permanência sobre eles durante uma duração definida. Se o seu interface mostra conteúdo ou controlos importantes só com hover do rato, os utilizadores de dwell vão acioná-los sem querer ou não conseguir aceder. Todo o conteúdo revelado por hover tem de ser acessível por clique/foco.Aprovado
Parcial
REPROVADO
N/D
 

Tecnologias assistivas auditivas

Verificar a compatibilidade com aparelhos auditivos, anéis magnéticos e garantir que existem alternativas visuais para todo o conteúdo áudio.

RefGravidadeRequisitoEstadoNotas / Provas
EN 301 549 §5.1.5ImportanteA saída áudio é compatível com streaming para aparelhos auditivos (Bluetooth LE Audio / MFi).Se o seu produto emite áudio (vídeos, alertas, chamadas), tem de ser recebido por aparelhos auditivos e implantes cocleares. O Bluetooth LE Audio e o Made for iPhone (MFi) são os principais protocolos. O conteúdo Web costuma transmitir pela saída áudio do dispositivo, mas confirme que nenhum tratamento personalizado contorna o caminho áudio do sistema.Aprovado
Parcial
REPROVADO
N/D
 
WCAG 1.2.1CríticoSão fornecidas alternativas visuais para todas as pistas e alertas áudio.Cada som, toques de notificação, beeps de erro, tons de sucesso, sons de mensagem, tem de ter equivalente visual. Os utilizadores surdos e com deficiência auditiva têm de receber a mesma informação visualmente. Use notificações no ecrã, mudanças de ícone ou vibração junto às pistas áudio.Aprovado
Parcial
REPROVADO
N/D
 
WCAG 1.2.4CríticoAs legendas são compatíveis com sistemas de anel magnético (telecoil).Em locais públicos, os anéis magnéticos transmitem áudio diretamente para os aparelhos auditivos via telecoil. Para apresentações Web ou quiosques em locais com anel, garanta que as legendas estão disponíveis como alternativa e que a saída áudio pode alimentar amplificadores de anel. As legendas têm de ser exatas e sincronizadas.Aprovado
Parcial
REPROVADO
N/D
 
WCAG 1.4.2ImportanteO volume é ajustável independentemente do volume do sistema.Os utilizadores com deficiência auditiva podem precisar de um volume diferente para multimédia e sons do sistema. Todo o conteúdo áudio deve ter controlos próprios de volume. Áudio em reprodução automática deve poder ser evitado. Os utilizadores têm de poder pausar, parar ou ajustar volume de qualquer áudio que toque mais de 3 segundos.Aprovado
Parcial
REPROVADO
N/D
 

Braille e TA cognitiva

Verificar a compatibilidade com displays Braille, navegação Braille, ferramentas de simplificação de texto e auxiliares de leitura.

RefGravidadeRequisitoEstadoNotas / Provas
EN 301 549 §11.5.2ImportanteO display Braille renderiza corretamente todo o conteúdo.Os displays Braille convertem o texto no ecrã em células Braille. O conteúdo tem de estar disponível como texto real (não imagens de texto nem texto renderizado em canvas). Caracteres especiais, símbolos matemáticos e emoji têm de renderizar corretamente em Braille ou ter alternativas textuais.Aprovado
Parcial
REPROVADO
N/D
 
EN 301 549 §11.5.2ImportanteAs teclas de routing do display Braille funcionam com todos os elementos interativos.Os displays Braille têm teclas de routing acima de cada célula que permitem clicar no elemento apresentado nessa posição. Todos os elementos interativos (ligações, botões, campos) têm de ser ativáveis pelas teclas de routing. Widgets personalizados têm de expor o seu carácter interativo à API de acessibilidade.Aprovado
Parcial
REPROVADO
N/D
 
EN 301 549 §5.1.3MenorO conteúdo é compatível com ferramentas de simplificação por síntese de voz.Ferramentas de acessibilidade cognitiva como Browsealoud, Rewordify e funcionalidades de simplificação dos navegadores dependem de HTML bem estruturado. Use cabeçalhos semânticos, parágrafos curtos, listas para informação sequencial e evite disposições aninhadas complexas que confundem a extração de conteúdo.Aprovado
Parcial
REPROVADO
N/D
 
EN 301 549 §5.1.3MenorCompatível com réguas de leitura e ferramentas de destaque do foco.Réguas de leitura, guias de linha e sobreposições de destaque ajudam utilizadores com dislexia e perturbações de atenção a acompanhar a posição de leitura. Estas ferramentas sobrepõem uma barra colorida ou escurecem o conteúdo envolvente. O seu site não pode interferir com estas sobreposições, evite elementos com z-index alto que cubram a sobreposição e garanta que o conteúdo flui corretamente.Aprovado
Parcial
REPROVADO
N/D
 
Gerado a partir de accessibilityref.eu/tools/at-interop-checklist