Requisitos do Selo Prata
Recolha de evidências para o Selo Prata
Utilize as listas de verificação para recolher evidências e confirmar se o sítio Web cumpre os requisitos de Acessibilidade e Usabilidade para obtenção do Selo Prata.
- Descarregar documento para recolha de evidências da Checklist 10 Aspetos Funcionais (xlsx, 125KB)
- Descarregar documento para recolha de evidências da Checklist Transação (xlsx, 87KB)
Kit do Selo de Usabilidade e Acessibilidade
Última atualização: 04-03-2020
Checklist "Transação"
Conformidade para com a checklist ”Transação”
1 · Formulários
1.1 A sequência de tabulação entre campos segue a sequência de preenchimento
A ordem de tabulação por entre os campos deve corresponder à sequência normal de preenchimento do formulário.
1.2 Os formulários com mais de 2 ecrãs de altura devem ser distribuídos por várias páginas
Os formulários não devem ser apresentados de forma excessivamente longa. Os formulários que ocupem mais de 2 ecrãs de altura devem ser distribuídos por tantos ecrãs quantos os necessários, para cumprir com esta regra. Os formulários longos podem também ter vários momentos de interação diferidos, solicitando ao utilizador a informação absolutamente necessária em cada etapa, em oposição à solicitação de toda a informação necessária logo num primeiro momento de interação.
1.3 Os formulários com mais de uma página têm a sequência de passos ilustrada
Os formulários distribuídos por várias páginas devem indicar no topo da página a sequência de passos necessária para os concluir, juntamente com a designação de cada passo. O utilizador deve ser capaz de selecionar os passos anteriores para retornar aos ecrãs respetivos e, se necessário, corrigir informação.
2 · Campos
2.1 O tamanho dos campos deve refletir o tamanho previsível dos dados
O tamanho dos campos deve refletir o tamanho previsível para a entrada dos dados. Por exemplo, um campo para telefone deve ter a largura estritamente necessária para conter todos os dígitos. Nem mais nem menos.
2.2 É usada revelação progressiva em vez de campos inativos
Em vez de mostrar campos inativos, o formulário deve esconder os campos dependentes do campo-chave sempre que este não tenha sido ativado. Ao ativar o campo-chave são exibidos os campos que dependem da condição nele definida.
2.3 As legendas dos campos são breves e claras
As legendas associadas aos campos devem ser claras e o mais breves possível, sem recorrer a grandes explicações. Se essas explicações forem necessárias, devem ser apresentadas num bloco de texto paralelo.
2.4 Campos obrigatórios devem ser claramente indicados como tal
A identificação não deve basear-se apenas na cor. A sinalética visual de identificação deve ser notória. Deve ser disponibilizado um equivalente alternativo compatível com as tecnologias de apoio usadas por utilizadores com necessidades especiais.
3 · Resposta
3.1 Em ações longas, o sistema deve indicar o que está a acontecer
O sistema deve indicar o que está a processar ou qual o tempo de espera expectável quando o utilizador desencadeia ações que levem a este comportamento.
3.2 Deve ser confirmado o sucesso da transação/envio de informação
O sucesso de uma transação deve ser claramente comunicado ao utilizador através de uma mensagem de confirmação.
4 · Erros
4.1 A informação já introduzida deve poder ser corrigida a qualquer momento
Toda a informação já transmitida pelo utilizador numa sessão pode ser corrigida, em qualquer momento, antes da transação ser finalizada.
4.2 As ações destrutivas nunca devem ser permanentes; deve ser sempre possível desfazer a operação
O utilizador deve poder recuperar de qualquer ação que tenha tomado durante a sessão.
4.3 As mensagens de erro são claramente identificadas junto aos campos de origem
As mensagens de erro devem ser apresentadas claramente associadas aos campos a que dizem respeito. Isto não invalida a necessidade de as apresentar numa lista sumário. Esta última técnica é particularmente útil em páginas longas.
4.4 As mensagens de erro devem mostrar os passos concretos para a resolução dos mesmos
As mensagens de erro devem ser claras e sucintas, não expondo desnecessariamente o utilizador a mecanismos internos do sistema, explicando claramente os passos necessários para que o utilizador resolva o problema.
Checklist "10 aspetos funcionais"
A checklist "10 aspetos funcionais" é para ser usada de acordo com a metodologia referida no artigo 9.º, n.º 1, alínea b) do Decreto-Lei n.º 83/2018:
- "1. Para os sítios Web, as entidades referidas no artigo 2.º devem adotar os seguintes procedimentos de monitorização:
- (...)
- b) Procedimento simplificado manual, correspondente a uma avaliação manual pericial a uma amostra de páginas que permita responder à diversidade de elementos constantes da lista de verificação para sítios Web publicada no sítio Web www.acessibilidade.gov.pt;"
1 · Menus de Navegação
1.1 O menu de navegação deve estar estruturado como uma lista de opções
Para que possa ser bem interpretado por tecnologias de apoio, os menus e submenus devem estar estruturados com elementos nativos, do tipo <ul>, ou com a semântica e o estado dos elementos identificados com técnicas em ARIA.
1.2 É possível selecionar as opções e as subopções do menu quer com rato quer com teclado
Deve ser possível percorrer a estrutura de navegação quer com um dispositivo apontador quer com o teclado.
1.3 As imagens-link, caso existam no menu, devem ter o correspondente equivalente alternativo em texto
As imagens corretamente legendadas permitem ser interpretadas como texto, tornando todas as opções de navegação acessíveis.
2 · Títulos e Subtítulos
2.1 Existe um título <h1> marcado na página
O título principal de cada página, que sumariza o seu conteúdo, deve ser identificado como o primeiro nível dos títulos (h1). Não deverá ser utilizado mais do que um <h1> por página.
2.2 Existe uma marcação hierarquizada de títulos e subtítulos na página (<h1>...<h6>)
Os títulos são empregues de forma hierárquica para melhor estruturar os conteúdos, das informações mais gerais às mais particulares. Deverão ser usados de forma consistente por todo o sítio Web.
3 · Tabelas de Dados
3.1 As células que constituem os cabeçalhos da tabela estão marcadas com o elemento <th>
Identificar os cabeçalhos de uma tabela ajuda a melhor identificar os eixos que caracterizam a informação em cada célula.
3.2 A legenda da tabela está marcada com o elemento <caption>
Todas as tabelas deverão conter uma legenda descritiva do seu conteúdo, incluindo as fontes da informação, se necessário.
4 · Formulários
4.1 Ao clicar com o rato na etiqueta, o cursor surge no respetivo campo de edição
De forma a tornar a seleção de campos pequenos mais fácil, a legenda deverá estar associada ao campo respetivo com o elemento <label>, pois desta forma aumenta-se a sua área clicável. Para os utilizadores de leitores de ecrã (pessoas cegas) a associação da etiqueta ao campo de edição é também fundamental.
4.2 É possível identificar os campos de preenchimento obrigatório quando se usa apenas um leitor de ecrã
Os campos obrigatórios devem ser preferencialmente agrupados na parte inicial de um formulário e claramente identificados como tal. Se não for possível, cada campo deverá estar identificado textualmente ou como Obrigatório ou como Opcional. Não deverão ser usados apenas símbolos ou cores como elemento identificador.
4.3 É possível localizar e ler as mensagens de erro usando apenas um leitor de ecrã
Os erros identificados no decorrer do preenchimento de um formulário deverão preferencialmente ser listados de forma condensada, direcionando cada elemento da lista ao respetivo campo. Cada campo deverá associar a mensagem de erro a si próprio. As mensagens de erro deverão ser breves e claras.
5 · Gráficos e Imagens-Link
5.1 A imagem ou gráfico tem um equivalente alternativo em texto curto e correto
As imagens não decorativas deverão ter uma descrição breve associada, nomeadamente através do uso do atributo <ALT>. Esta legenda deve descrever fielmente o propósito da imagem no contexto em que se encontra.
5.2 O gráfico é acompanhado de uma descrição longa
Gráficos resultantes de análise de dados deverão ser acompanhados da tabela de dados que lhe deu origem, de forma a preservar o acesso à informação completa.
5.3 As imagens-link têm um equivalente alternativo correto
As hiperligações compostas apenas por uma imagem obrigam que esta tenha um equivalente alternativo em texto que represente fielmente o destino da hiperligação.
6 · Contraste
6.1 No corpo de um documento, o rácio de contraste entre a cor do texto normal (menor que 18 pontos ou menor que 14 pontos negrito) e a cor do fundo é superior a 4,5:1
Deve assegurar-se no corpo do documento que o rácio de contraste entre a cor do texto e a cor de fundo é, no mínimo, de 4,5:1, de forma a assegurar a sua legibilidade para utilizadores com deficiências da visão.
6.2 O rácio de contraste entre a cor do texto de tamanho grande (maior ou igual que 18 pontos ou maior ou igual que 14 pontos negrito) e a cor do fundo é superior a 3:1
Os textos de tamanho superior a 18 pontos, ou os textos de tamanho superior a 14 pontos mas a negrito, devem assegurar um rácio de contraste mínimo de 3:1 entre a cor do texto e a cor do fundo.
7 · Players
7.1 Deve ser possível ativar os botões de controlo do leitor quer com o rato quer com o teclado
Os leitores de multimédia não devem iniciar automaticamente a reprodução dos elementos e têm de ser operáveis usando apenas um rato ou usando apenas um teclado.
7.2 O vídeo ou o áudio deve conter preferencialmente legendas fechadas sincronizadas. Caso não seja possível, no mínimo, deve disponibilizar-se uma transcrição textual
O uso de legendas fechadas destina-se essencialmente a pessoas surdas. Recomendam-se para a produção das referidas legendas técnicas de tradaptação conhecidas para o efeito bem como o enriquecimento das legendas de sons cuja mensagem não seja percetível visualmente (por ex., o toque de uma campaínha de uma porta). Para vídeos com mensagens eminentemente visuais (por ex., um vídeo com música de fundo que passa um conjunto de mensagens apenas percetíveis à visão), os mesmos devem ter uma versão equivalente alternativa com produção de audiodescrição. A audiodescrição é fundamental para que pessoas cegas ou com baixa visão possam percecionar a mensagem veiculada.
8 · Estrutura da Página
8.1 Quando se retira a CSS, todos os elementos HTML devem alinhar à esquerda
Quando se desativam todos os estilos visuais, o conteúdo da página é apresentado alinhado à esquerda e apresenta-se de forma linear.
8.2 Quando se retira a CSS, a informação aparece numa ordem lógica
Tendo em conta que o posicionamento de elementos no código pode não refletir a ordem visual de leitura, deve ser assegurada a ordem correta do conteúdo quando se desativam os estilos visuais.
8.3 Quando se retira a CSS, deve ser possível reconhecer a semântica dos diversos elementos
Os elementos que estruturam o conteúdo devem estar semanticamente bem estruturados, usando os elementos de HTML apropriados a cada tipo de conteúdo, como título, parágrafos, listas, ...
8.4 Quando se retira a CSS, a informação relevante permanece visível
Toda a informação visível deve permanecer na página sob forma textual, quando se desativam os estilos visuais.
8.5 A maquetização da página é feita sem recorrer ao elemento <table>
A estrutura de composição gráfica da página não é feita recorrendo a elementos de tabela mas sim a uma maior diversidade de elementos semânticos (por ex., <main>) e genéricos (por ex., <div>), que permitem a recomposição visual para diferentes tipos e dimensões de ecrã.
