Relatório Avaliação de Candidatura
Alerta Lobos

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #6 Não é possível selecionar as opções do menu com a tecla Enter, que reencaminha o utilizador para a pesquisa

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

  É possível selecionar as opções e as subopções do menu quer com rato quer com teclado.

  • Ver requisito 1.2 da lista 10 aspetos

  Evidências:
  O botão do menu hambúrguer apresenta os seguintes comportamentos incorretos quando operado por teclado:

  • A tecla Enter não abre o menu: A ativação com Enter não abre o menu de navegação; em vez disso, redireciona o utilizador para a página de pesquisa (https://alertalobos.cm-camaradelobos.pt/pesquisa?ref=), comportamento claramente não intencional.

  

  Figura 1 - Página de pesquisa para onde o utilizador é reencaminhado quando usa a tecla Enter para abrir o menu

  • O comportamento incorreto da tecla Enter sugere que existe um evento de formulário ou link subjacente que intercepta a ação antes do handler do botão.

  • O botão não tem aria-expanded para comunicar o estado aberto/fechado do menu ao leitor de ecrã.

  • O botão não tem aria-controls para associar programaticamente o botão ao painel de navegação que controla.

  Como consequência, os utilizadores que dependem exclusivamente de teclado ou de tecnologias de apoio não conseguem aceder às opções de navegação das restantes páginas do site.

  Recomendações:

  • Corrigir o handler de teclado do botão para que tanto Enter como Espaço abram o menu de navegação, sem provocar redirecionamentos indesejados para a página de pesquisa.
  • Adicionar o valor de aria-expanded ao botão, conforme o estado do menu: aria-expanded="false" quando o menu está fechado (botão do menu hambúrguer) e aria-expanded="true" quando o menu está aberto (botão do X).
  • Após a abertura do menu, mover o foco programaticamente para o primeiro item da lista de navegação.

  Podem consultar a página Menu Button Pattern da WCAG como referência.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #7 O botão do menu hambúrguer não tem texto alternativo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.3

  As imagem-link, caso existam no menu, devem ter o correspondente equivalente alternativo em texto.

  • Ver requisito 1.3 da lista 10 aspetos

  Evidencias:
  O botão do menu hambúrguer não possui um texto alternativo acessível, sendo anunciado pelo leitor de ecrã apenas como “Botão”. Embora o elemento <button> inclua o atributo title="Menu", esta informação não é consistentemente interpretada pelos leitores de ecrã. Ferramentas como o NVDA, TalkBack e VoiceOver, por exemplo, não anunciam o conteúdo do atributo title, o que compromete a compreensão da funcionalidade do botão por utilizadores que recorrem a tecnologias de apoio.

  

  Figura 1 - Leitor de ecrã Talkback apenas lê o botão do menu hambúrguer como "Botão." em mobile

  O mesmo se aplica ao botão "X" quando o painel está aberto, que é lido apenas como "Botão", apesar do atributo title="Menu".

  Recomendações:
  O texto alternativo do botão menu deve comunicar corretamente a função. . Deve ser adicionado o texto alternativo correto ao elemento <button> do menu hambúrguer, através de um aria-label="Menu" ou aria-label="Abrir Menu", para evitar que o leitor de ecrã as identifique apenas como “botão” ou “link”.

  O mesmo se aplica ao botão "X" quando o painel do menu está aberto, que deve ter aria-label="Fechar menu".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #8 Todas as páginas têm "Alerta Lobos" como <h1>

  etiqueta: R 2.1etiqueta: chk 10 webetiqueta: NOK

  Existe um título <h1> marcado na página.

  • Ver requisito 2.1 da lista 10 aspetos

  Evidências:
  Todas as páginas do site têm um <h1> atribuído a "Alerta Lobos", não identificando corretamente o título de cada página.

  • Na página inicial https://alertalobos.cm-camaradelobos.pt/, o <h1> está atribuído a um texto escondido, em vez de estar atribuído ao texto "Alerta Lobos" visível. Por este motivo, o existe um <h1> atribuído ao texto escondido "Alerta Lobos" e um <h2> atribuído ao texto visível "Alerta Lobos".

  • Na página "Nova Ocorrência" https://alertalobos.cm-camaradelobos.pt/nova-ocorrencia, o <h1> está atribuído a um texto invisível "Alerta Lobos" e o título visível da página está marcado com <h3>.

  

  .

  O mesmo acontece nas restantes páginas, cujo título visível da página está marcado com <h2> ou <h3>.

  • https://alertalobos.cm-camaradelobos.pt/pesquisa
  • https://alertalobos.cm-camaradelobos.pt/pesquisa?ref=bG9iaXM=
  • https://alertalobos.cm-camaradelobos.pt/que-ocorrencias-posso-submeter-no-alertalobos

  Na seguinte página, o título visível da página nem sequer está marcado como <h1>.

  • https://alertalobos.cm-camaradelobos.pt/lobos-digital

  Na seguinte página, existem dois elementos <h1> atribuídos.

  • https://alertalobos.cm-camaradelobos.pt/acessibilidade

  Recomendações:
  Devem rever todas as páginas do site, de forma a confirmar que o elemento <h1> está atribuído ao título principal de cada página:

  • Na homepage, o elemento <h1> deveria estar atribuído ao título visível principal.
  • Nas páginas interiores, o elemento <h1> deveria estar atribuído apenas ao título visível que identifica a página. O título "Alerta Lobos" invisível das páginas secundárias não deve estar marcado como título da página.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #9 Títulos marcados no código não são apresentados visualmente

  etiqueta: R 2.2etiqueta: chk 10 webetiqueta: NOK

  Existe uma marcação hierarquizada de títulos e subtítulos na página <h1>...<h6>.
  – ver requisito 2.2 na lista 10 aspetos

  Evidências:
  Existem páginas com títulos invisíveis marcados, incluindo títulos <h3>, como "Avisos" na página Nova Ocorrência, que não existem na hierarquia visível dos títulos.

  

  Figura 1 - Hierarquia de títulos da página "Nova Ocorrência"

  

  Figura 2 - Página "Nova Ocorrência" com título visível que não corresponde à hierarquia dos títulos marcada no código

  Recomendações:
  Devem rever todas páginas do site (homepage e interiores) para garantir que respeitam a hierarquia de títulos e subtítulos, o que implica:

  • Ter 1 título <h1> (que marca o texto que representa o título da página ou, no caso da Homepage, o logo da entidade);
  • Ter as várias secções do documento marcadas com <h2>;
  • Ter as várias subseções de <h2> marcadas com <h3>, as subsecções destas com <h4> e assim hierarquicamente encadeados até <h6>;
  • Evitar ter elementos de hierarquia inferior sem um elemento de hierarquia imediatamente superior (subseções órfãs). Por exemplo, ter um <h3> sem a correspondente <h2>, ou <h4> sem a correspondente <h3>.

  É importante a hierarquia dos títulos no código corresponder à hierarquia visível.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #10 Utilização redundante de aria-label nos cabeçalhos <th> da tabela

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 3.1

  As células que constituem os cabeçalhos da tabela estão marcadas com o elemento <th>.
  – ver requisito 3.1 na lista 10 aspetos

  Evidencias:
  Os elementos <th> da tabela possuem o atributo aria-label, apesar de já conterem texto visível que identifica corretamente cada coluna.

  Exemplo:

  <th aria-label="Categoria">Categoria</th>
  <th aria-label="Subcategoria">Subcategoria</th>
  <th aria-label="Ocorrência">Ocorrência</th>
  

  O conteúdo textual de um elemento <th> já é utilizado pelas tecnologias de apoio para determinar o nome acessível do cabeçalho da coluna.

  A utilização de aria-label com exatamente o mesmo valor do texto visível não acrescenta informação adicional e introduz complexidade desnecessária.

  Esta abordagem pode ainda originar problemas de manutenção caso o texto visível seja alterado sem atualização do respetivo atributo aria-label.

  Qual seria o impacto?

  • Código mais complexo sem benefício para acessibilidade.
  • Maior risco de inconsistências entre o texto visível e o nome acessível.
  • Dificulta a manutenção futura da tabela.

  

  Figura 1 - HTML da tabela mostra títulos da tabela com conteúdo além do aria-label.

  Recomendações:
  O primeiro princípio do ARIA é: "No ARIA is better than bad ARIA."

  Devem remover os atributos aria-label redundantes dos elementos e permitir que o nome acessível seja determinado a partir do conteúdo textual do próprio cabeçalho.

  Nota: Se a tabela tiver sido gerada pelo DataTables, esta alteração pode ser direcionada para a configuração do componente e não para o HTML final renderizado.

etiqueta: OK (no entanto contém 1 melhoria que se recomenda efetuar)

Lista de evidências recolhidas:

• evidência: issue #11 O <caption> da tabela está visualmente oculto

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 3.2

  A legenda da tabela está marcada com o elemento <caption>
  – ver requisito 3.2 na lista 10 aspetos

  Evidências:
  O elemento <caption> da tabela de ocorrências tem a classe sr-only, o que o torna invisível para utilizadores que navegam visualmente.

  <caption class="sr-only">Últimas Ocorrências</caption>
  

  O texto "Últimas Ocorrências" já existe num título visível imediatamente antes da tabela. No entanto, o mesmo texto aparece repetido num <caption> oculto, sem qualquer associação programática entre os dois. Para utilizadores de leitores de ecrã, isto resulta no anúncio do título duas vezes.

  

  Figura 1 - HTML da tabela tem um caption escondido visualmente

  Recomendações:

  • Tornar o elemento visível para todos os utilizadores, removendo a classe sr-only.
  • O título existente pode ser mantido como parte da estrutura de navegação da página, mas com um nome diferente do caption. O caption deve especificamente descrever o conteúdo da tabela apresentada.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #12 Existem campos sem label associada ao input

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

  Ao clicar com o rato na etiqueta, o cursor surge no respetivo campo de edição.
  – ver requisito 4.1 na lista 10 aspetos

  Evidências:
  A página principal apresenta um campo de pesquisa que não possui o elemento <label>, apenas o elemento <input> com o palceholder="Inserir referência".

  

  Figura 1 - Campo de input da página inicial

  O mesmo acontece nas páginas interiores que têm o campo de pesquisa no topo da página, como a página da Declaração de Acessibilidade.

  

  Figura 2 - Campo de input da página de Declaração de Acessibilidade

  E na página Pesquisa, também apenas existe o campo de input, sem a label.

  

  Figura 3 - Campo de input da página Pesquisa

  Já no formulário da página Nova Ocorrência, existem campos de input e checkboxes bem estruturados, mas os campos de dropdown não recebem o foco quando se clica na label.

  

  Figura 4 - Campo de dropdown da página Nova Ocorrência

  Recomendações:
  Os campos de formulários, como por exemplo, o <input>, <select> ou <areatext>, devem ter as suas legendas estruturadas com o elemento <label> , para que ao clicar na legenda, apareça o cursor. Isso pode ser feito por exemplo, utilizando o atributo for ou inserir o elemento dentro da label na estrutura do HTML.

  Por exemplo, os campos da secção Dados Pessoais da página Nova Ocorrência estão devidamente implementados. Quando se clica na label do campo, o cursor aparece no respetivo campo.

  Adicionalmente, é necessário remover o atributo aria-hidden="true" e tabindex="-1" dos campos das dropdowns e assegurar que a gestão de foco é efetuada sobre o elemento <input> apropriado, permitindo a correta interação por parte dos utilizadores de tecnologias de apoio, como leitores de ecrã. Como referência para a implementação, podem [consultar o exemplo do elemento select da W3schools`](https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_select).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #13 Não há informação clara sobre o que é o asterisco nos campos de preenchimento obrigatório

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.2

  É possível identificar os campos de preenchimento obrigatório quando se usa apenas um leitor de ecrã.
  – ver requisito 4.2 na lista 10 aspetos

  Evidências:
  Os campos de preenchimento obrigatório apresentam um asterisco, no entanto não existe uma definição do significado do asterisco em nenhuma parte do formulário da página Nova Ocorrência.

  

  Figura 1 - Campos obrigatórios com asterisco., mas sem definição no formulário

  Recomendações:
  Os campos obrigatórios dos formulários devem estar devidamente identificados como tal. Idealmente, devem apresentar o texto “Obrigatório” à frente da legenda do campo. Pode-se colocar um * no campo obrigatório, desde que o significado do * seja mencionado, preferencialmente, no início do formulário.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #15 Imagem decorativa com texto alternativo incorreto e língua estrangeira

  etiqueta: chk 10 webetiqueta: R 5.1etiqueta: NOK

  A imagem ou gráfico tem um equivalente em texto curto e correto.
  – ver requisito 5.1 na lista 10 aspetos

  Evidências:
  Existem imagens decorativas com texto alternativo, sendo lidas pelo leitor de ecrã, e acrescentando ruído ao conteúdo da página.

  No caso da imagem decorativa do logótipo da página inicial, o texto alternativo é "Ocorrências_Lobos", estando incorreto e confuso para o contexto onde se encontra.

  

  Figura 1 - Figura decorativa do logo na página inicial

  No caso da imagem decorativa dos resultados da pesquisa, o texto alternativo é "Warning", estando incorreto e numa língua diferente da língua do site.

  

  Figura 2 - Figura decorativa dos resultados da pesquisa

  Recomendações:
  Na imagem decorativa da página inicial e dos resultados da pesquisa, devem alterar o texto alternativo para que fique vazio, ou seja alt="". Desta forma, o leitor de ecrã irá ignorar a imagem decorativa, uma vez que não tem utilidade, nem função para o contexto onde se encontra.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #16 Não estão presentes gráficos no site

  etiqueta: N/Aetiqueta: chk 10 webetiqueta: R 5.2

  O gráfico é acompanhado de uma descrição longa.
  – ver requisito 5.2 na lista 10 aspetos

  Evidências:
  Não estão presentes gráficos no site.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #17 Imagens link com texto alternativo incorreto

  etiqueta: R 5.3etiqueta: chk 10 webetiqueta: NOK

  As imagens-link têm um equivalente alternativo correto.
  – ver requisito 5.3 na lista 10 aspetos

  Evidências:
  Existem imagens-link com texto alternativo, mas não descrevem corretamente a sua função.

  Por exemplo, a imagem informativa do logótipo no topo das páginas interiores tem o alt="MainLogo", não descrevendo a função do link que regressa à página inicial.

  

  Figura 1 - Figura informativa do logo no topo das páginas interiores

  A imagem informativa no menu hambúrguer, no fundo da lista de opções, tem o alt="Logotipo da Câmara Municipal de Câmara de Lobos, que remete para a homepage", sendo demasiado comprido e redudante, não anunciando imediatamente a sua função.

  

  Recomendações:
  Na imagem-link do logótipo no topo das páginas interiores, devem alterar o texto alternativo para alt="Página inicial de Alerta Lobos".

  Na imagem-link do logótipo posicionado no fundo do menu hambúrguer, devem alterar o texto alternativo para alt="Página inicial da Câmara de Lobos".

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #20 Não estão presentes leitores de multimédia no site

  etiqueta: N/Aetiqueta: chk 10 webetiqueta: R 7.1

  Deve ser possível ativar os botões de controlo do leitor quer com o rato quer com o teclado.
  – ver requisito 7.1 na lista 10 aspetos

  Evidências:
  Não estão presentes leitores de multimédia no site.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #21 Não estão presentes leitores de multimédia no site

  etiqueta: N/Aetiqueta: chk 10 webetiqueta: R 7.2

  O vídeo ou áudio deve conter preferencialmente legendas fechadas sincronizadas.
  – ver requisito 7.2 na lista 10 aspetos

  Evidências:
  Não estão presentes leitores de multimédia no site.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #22 Informação desliza de forma automática e contínua

  etiqueta: chk 10 webetiqueta: R 8.1etiqueta: NOK

  Quando se retira a CSS, todos os elementos HTML devem alinhar à esquerda.
  – ver requisito 8.1 na lista 10 aspetos

  Evidências:
  "O slider contínuo de informação não é corretamente interpretado pelos leitores de ecrã. O conteúdo é atualizado/movido automaticamente sem ser anunciado de forma adequada, dificultando o acesso à informação por utilizadores de tecnologias de apoio.

  

  Figura 1 - Slider contínuo com CSS aplicado

  

  Figura 2 - Slider contínuo sem CSS

  Recomendações
  O CSS é a linguagem utilizada para estilizar um documento HTML e descreve como os elementos devem ser apresentados. Ao removermos o layout, conseguimos verificar se é possível reconhecer o conteúdo e os elementos semânticos do documento HTML mesmo sem os estilos aplicados.

  Recomenda-se disponibilizar uma alternativa acessível, permitir o controlo da rotação da informação e garantir a correta exposição do conteúdo através de semântica HTML e atributos ARIA apropriados, OU seja, evitar movimento automático contínuo sempre que possível, disponibilizar controlos para pausar, parar ou avançar o conteúdo, e garantir que toda a informação do slider está disponível numa estrutura acessível (lista, tabela, secções, etc.).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #23 Quando se retira a CSS, a informação não aparece numa ordem lógica

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

  Quando se retira a CSS, a informação aparece numa ordem lógica.
  – ver requisito 8.2 na lista 10 aspetos

  Evidências:
  Ao desativar o CSS, verifica-se que a ordem de apresentação da informação no HTML não corresponde à sequência lógica do conteúdo. Esta situação é particularmente evidente no menu de navegação: as opções do menu são apresentadas apenas após o link "Nova Ocorrência", em vez de surgirem imediatamente após o respetivo botão de abertura do menu.

  

  Figura 1 - Página inicial sem CSS aplicado, onde é possível observar os botões de abrir e fechar menu

  

  _Figura 2 - Página inicial sem CSS aplicado, com as opções do menu mais afastada

  Recomendações
  Reorganizar a estrutura do HTML de forma a garantir que a ordem dos elementos no código reflete a ordem lógica e semântica do conteúdo apresentado. Desta forma, mesmo na ausência de CSS, a informação continuará a ser apresentada de forma coerente e intuitiva para todos os utilizadores, incluindo aqueles que recorrem a tecnologias de apoio.

etiqueta: OK (no entanto contém 1 melhoria que se recomenda efetuar)

Lista de evidências recolhidas:

• evidência: issue #24 Botões estão estruturados semanticamente como links

  etiqueta: chk 10 webetiqueta: R 8.3etiqueta: melhoria

  Quando se retira o CSS, deve ser possível reconhecer a semântica dos diversos elementos.
  – ver requisito 8.3 na lista 10 aspetos

  Evidências:
  Ao remover o CSS, é possível verificar que alguns elementos que visualmente se apresentam como botões estão, na realidade, estruturados semanticamente como links ()."

  

  Figura 1 - Link "Nova Ocorrência semanticamente estruturado como link, embora visualmente seja um botão/

  Recomendações:
  Garantir que os elementos interativos utilizam a marcação HTML semanticamente adequada à sua função. Elementos que executam ações na página devem ser implementados com , enquanto elementos destinados à navegação devem utilizar . Esta correção melhora a acessibilidade, a compatibilidade com tecnologias de apoio e a navegação por teclado.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #26 O link "Ir para o conteúdo" não é apresentado visualmente, nem suficientemente descritivo e remete para um main inexistente

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.5

  A maquetização da página é feita sem recorrer ao elemento <table>.
  – ver requisito 8.5 na lista 10 aspetos

  Evidências:
  Quando se navega com o leitor de ecrã, o primeiro elemento anunciado na página é o link "Ir para o conteúdo" e que remete para o elemento <main>.

  

  _Figura 1 - Leitor de ecrã lê o link "Ir para conteúdo" _

  

  Figura 2 - HTML do link "Ir para conteúdo".

  No entanto, esse link não aparece visualmente, apenas é anunciado pelo leitor de ecrã e acessível para pessoas que usam essa tecnologia de apoio.

  O mesmo link não se encontra acessível, por exemplo, para pessoas com mobilidade reduzida que navegam apenas com teclado, sem recorrerem ao leitor de ecrã.

  Recomendações:

  • Alterar a descrição do link "Ir para o conteúdo" para "Saltar para o conteúdo principal" ou "Ir para o conteúdo principal" para ser suficientemente descritivo da sua função.
  • • Adicionar landmarks à página html, incluindo a landmark <main> que envolve o conteúdo principal, para a qual o link "Saltar para o conteúdo principal" deve remeter.
  • Apresentar o link "Saltar para o conteúdo principal" visualmente quando recebe o foco do teclado. Podem consultar o link "Saltar para o conteúdo principal" do site do selo, https://selo.usabilidade.gov.pt/, como referência.

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #27 O foco do teclado não é movido para a dialog após abertura

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.1

  Quando a caixa de diálogo é aberta, o foco (cursor do Browser) move-se para um elemento dentro da caixa de diálogo
  – ver requisito 9.1 na lista 10 aspetos

  Evidências:
  A tecla Espaço abre o menu hambúrguer, mas o foco não é gerido: Embora a tecla Espaço consiga abrir o menu, o foco do teclado não é movido para as opções do menu após a sua abertura, impossibilitando a navegação pelas mesmas.

  

  Figura 1 - Foco do teclado não é movido para o botão de fechar menu quando o painel é aberto

  Quando se submete o formulário Nova Ocorrência, se existirem erros, surge uma dialog. No entanto, o foco não é movido para a dialog, continuando a percorrer os elementos atrás dessa.

  

  Figura 2 - Foco do teclado não é movido para o botão de fechar dialog quando o painel é aberto

  Recomendações:
  Devem garantir que o botão do menu hambúrguer possa ser ativado com a tecla Space e Enter e, quando a dialog é aberta, o foco do teclado deve ir para o primeiro elemento da dialog que, neste caso do menu, é o botão fechar, representado pelo X.

  Aplicar a mesma lógica à dialog que surge após submissão do formulário, e que cujo primeiro elemento da dialog é também o botão fechar, representado pelo X.

  Como referência para construir uma dialog acessível podem consultar a página da Modal Dialog Example da W3C.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #28 A navegação com teclado não fica circunscrita aos elementos da dialog

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.2

  Quando uma caixa de diálogo está aberta, a navegação com teclado (Browser ou Tecnologia de apoio) tem de ficar circunscrita aos elementos que compõem a caixa de diálogo
  – ver requisito 9.2 na lista 10 aspetos

  Evidências:
  Quando se submete o formulário Nova Ocorrência, aparece uma caixa de diálogo com o aviso de que existem campos incorretos ou vazios. No entanto, o foco não fica apenas circunscrito à dialog, continuando a percorrer os elementos atrás da dialog.

  

  Figura 1 - Dialog após submissão do formulário

  O mesmo acontece com a dialog do menu de navegação quando é aberta.

  

  Figura 2 - Dialog do menu de navegação

  Recomendações:
  Deve ser garantido que o botão do menu hambúrguer possa ser ativado tanto pela tecla Enter como pela tecla Espaço (Space). Quando a dialog for aberta, o foco do teclado deve ficar restrito aos elementos interativos existentes no seu conteúdo, impedindo a navegação para elementos localizados atrás da dialog (focus trap).

  O utilizador só deverá conseguir voltar a percorrer o conteúdo da página subjacente após fechar a dialog, seja através do botão Fechar ou da tecla Escape.

  Aplicar a mesma lógica à dialog que surge após submissão do formulário.

  Como referência para construir uma dialog acessível, podem consultar a página da Modal Dialog Example da W3C.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #29 As dialog têm o botão de fechar, mas não são operáveis por teclado

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.3

  A caixa de diálogo tem de ter um mecanismo que permita sair ou fechar a caixa, quer através de teclado quer através de um dispositivo apontador
  – ver requisito 9.3 na lista 10 aspetos

  Evidências:
  Apesar de visualmente terem o botão de "Fechar" na dialog, não é possível interagir com os mesmos através do teclado.

  

  Figura 1 - Botão de fechar do menu não é operável por teclado

  Quando se submete o formulário Nova Ocorrência, se existirem erros, surge uma dialog. No entanto, não é possível focar com o teclado no botão de fechar.

  

  Figura 2 - Botão de fechar dialog do formulário não é operável por teclado

  Recomendações:
  Devem garantir que os botões das dialogs são focáveis e operáveis por teclado, e com a tecla Escape.

  Como referência para construir uma dialog acessível podem consultar a página da Modal Dialog Example da W3C.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #30 Não é possível confirmar se o foco regressa ao botão que evocou as dialogs

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.4

  Quando a caixa de diálogo fecha, o foco (cursor do Browser) deve voltar ao elemento interativo que a invocou
  – ver requisito 9.4 na lista 10 aspetos

  Evidências:
  Considerando que não é possível interagir com os botões de fechar das dialog com o teclado, como reportado no issue 29, não é possível confirmar se o foco regressa ao elemento que evocou a dialog de erro do formulário de Nova ocorrência, ou a dialog do menu de navegação.

  Recomendações:
  Garantir que o foco retorne ao botão que acionou a modal é uma prática que beneficia especialmente pessoas que utilizam navegação por teclado ou leitores de ecrã, ajudando-as a manter-se orientadas dentro da interface.

  Ao fechar uma modal, se o foco é perdido ou deslocado para um local inesperado, os utilizadores precisarão percorrer novamente a interface até chegar no local desejado para continuar a interação desejada.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #31 O site não apresenta ficheiros PDF

  etiqueta: N/Aetiqueta: chk 10 webetiqueta: R 10.1

  Nos ficheiros PDF é possível, no mínimo, extrair o conteúdo textual para formato TXT.
  – ver requisito 10.1 na lista 10 aspetos

  Evidências:
  O site não apresenta ficheiros de PDF.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #32 Não existe um resumo do propósito do site na homepage

  etiqueta: chk conteúdoetiqueta: R 1.1etiqueta: NOK

  O sítio Web apresenta um resumo breve do seu propósito, visível sem fazer scroll.
  – ver requisito 1.1 na lista Conteúdo

  Evidências:
  A página inicial não apresenta nenhum conteúdo que descreve o propósito do site.

  

  ´

  Figura 1 - Página inicial de Alerta Lobos sem descrição do propósito do site.

  Recomendações:
  O propósito do website difere da missão ou do objetivo da entidade. O propósito deve transmitir, de forma clara, o que o utilizador pode efetivamente encontrar e realizar no website. Esse propósito deve ser imediatamente visível na página, sem ser necessário fazer scroll, avançar no slideshow, entre outros.

  Como referência de uma boa prática, é possível verificar no website acessibilidade.gov que o seu propósito está escrito no topo da página.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #33 Não existe um glossário para termos complexos

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.2

  Os termos mais complexos têm uma definição agregada.
  – ver requisito 1.2 na lista Conteúdo

  Evidências:
  Não está presente um glossário no site para palavras complexas, como "Ocorrência".

  Recomendações
  Em sites com termos técnicos ou complexos, que sejam difíceis de compreender, deve existir uma página de glossário com as definições dessas palavras. O glossário deve apresentar a definição dos termos e conceitos de forma clara e breve, para que seja facilmente compreensível pelos utilizadores.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #35 Não há referência à entidade responsável pelos conteúdos

  etiqueta: chk conteúdoetiqueta: R 1.4etiqueta: NOK

  A informação sobre a entidade responsável pelo conteúdo está em todas as páginas.
  – ver requisito 1.4 na lista Conteúdo

  Evidências:
  Não foi encontrado o nome da entidade responsável pelo conteúdo em nenhuma página.

  Recomendações:
  Todas as páginas devem apresentar o nome da entidade responsável pelos conteúdos publicados no site. O nome da entidade pode ser apresentado através de um logótipo ou texto, mas deve estar por extenso, como é possível observar na autenticacao.gov.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #38 Existem blocos de texto com mais de 100 caracteres por linha

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.3

  Blocos e linhas de texto com largura não superior a 100 caracteres.
  – ver requisito 2.3 na lista Conteúdo

  Evidências:
  Existem blocos de texto com mais de 100 caracteres por linha, como acontece na página da Declaração de Acessibilidade ou Que ocorrência posso submeter no Alerta Lobos? .

  

  Figura 1 - Texto da página "Que ocorrências posso submeter no Alerta Lobos"

  

  Figura 2 - Contagem dos caracteres

  Recomendações:
  Para assegurar uma boa leitura, as linhas de texto devem ter até 80 caracteres (incluindo espaços). No limite, podem ir até aos 100 caracteres (incluindo espaços).

  Recomenda-se que seja definida uma largura máxima para as caixas de texto (max-width, em CSS), com unidades relativas ao tamanho de fonte (unidades em ou rem) para garantir que não é ultrapassado o número máximo de caracteres por linha.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #41 A navegação principal do site está colapsada em desktop e a pesquisa desaparece em mobile

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.2

  A navegação principal está sempre visível e sempre no mesmo local.
  – ver requisito 3.2 na lista Conteúdo

  Evidências:
  O menu em desktop encontra-se colapsado. Nas páginas interiores, além do menu, é apresentada uma barra de pesquisa que desapareceu na versão mobile do site.

  

  Figura 1 - Pesquisa no topo da página e menu hambúrguer na versão desktop do site.

  

  Figura 2 - Pesquisa desaparece na versão mobile do site

  Recomendações:
  No caso de breakpoints superiores, normalmente considerados para desktop, devem estar imediatamente visíveis no ecrã pelo menos as opções de 1º nível porque, à partida, existe espaço para tal.

  No caso de breakpoints inferiores, normalmente considerados para tablet e mobile, o menu pode manter-se colapsado.

  Independentemente da página, o menu deve estar sempre posicionado no mesmo local.

  Além disso, adicionar um botão que abra a pesquisa na versão mobile do site, porque é apenas é possível abrir a pesquisa através da opção do menu, reduzindo a findability.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #43 Não existem páginas longas

  etiqueta: N/Aetiqueta: chk conteúdoetiqueta: R 4.1

  Os documentos longos têm um índice no topo com hiperligações internas para o mesmo.
  – ver requisito 4.1 na lista Conteúdo

  Evidências:
  Não existem páginas longas, uma vez que não existem páginas na versão desktop do site que ultrapassem três ecrãs de altura.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #50 Não estão presentes formulários com mais de 2 ecrãs de altura

  etiqueta: N/Aetiqueta: chk transaçãoetiqueta: R 1.2

  Os formulários com mais de 2 ecrãs de altura devem ser distribuídos por várias páginas.
  – ver requisito 1.2 na lista Transação

  Evidências:
  Não estão presentes formulários com mais de 2 ecrãs de altura no site.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #51 Não estão presentes formulários com mais de 1 página

  etiqueta: N/Aetiqueta: chk transaçãoetiqueta: R 1.3

  Os formulários com mais de uma página têm a sequência de passos ilustrada.
  – ver requisito 1.3 na lista Transação

  Evidências:
  Não estão presentes formulários com mais de 1 página no site.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #53 Os fomulários não tem campos dependentes

  etiqueta: N/Aetiqueta: R 2.2etiqueta: chk transação

  É usada revelação progressiva em vez de campos inativos.
  – ver requisito 2.2 na lista Transação

  Evidências:
  Os fomulários do site não tem campos dependentes.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #55 Mensagens de erro com texto redundante

  etiqueta: R 2.4etiqueta: NOKetiqueta: chk transação

  Campos obrigatórios devem ser claramente indicados como tal.
  – ver requisito 2.4 na lista Transação

  Evidências:
  As mensagens de erro do formulário Nova Ocorrência apresentam informação do campo ser obrigatório várias vezes, devido aos atributo required e aria-required, sendo redundante.

  

  Figura 1 - Campo com mensagem de erro lido pelo leitor de ecrã NVDA

  Recomendações:
  Optar pelo atributo required, que informa todas as tecnologias de apoio. incluindo leitor de ecrã, que o campo é obrigatório. Remover o atributo aria-required, que apenas informa o leitor de ecrã, para evitar redundância.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #56 O loader não tem texto alternativo e não é comunicado pelo leitor de ecrã

  etiqueta: NOKetiqueta: chk transaçãoetiqueta: R 3.1

  Em ações longas, o sistema deve indicar o que está a acontecer.
  – ver requisito 3.1 na lista Transação

  Evidências:
  Quando o utilizador submete o formulário. aparece um loader visualmente, no entanto, esse loader não possui texto alternativo e o mesmo não é anunciado pelo leitor de ecrã. Caso a página fique infinitamente em loading, um utilizador cego não saberá o que está a acontecer, se é um loading de espera, processamento, etc.

  

  Figura 1 - Loader do site

  Recomendações:

  Devem garantir que esse loader:

  • tem um role="status".
  • tem um aria-live="polite" que anuncia a mensagem assim que o utilizador terminar o que está a fazer.
  • tem aria-label ou texto interno que fornece a mensagem que será lida. (ex: aria-label="A carregar página. Aguarde, por favor.").

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #59 Não existem ações destrutivas no site

  etiqueta: N/Aetiqueta: R 4.2etiqueta: chk transação

  As ações destrutivas nunca devem ser permanentes, deve ser sempre possível desfazer a operação.
  – ver requisito 4.2 na lista Transação

  Evidências:
  Não existem ações destrutivas no site.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #61 Mensagens de erro pouca claras sobre a resolução dos erros

  etiqueta: NOKetiqueta: chk transaçãoetiqueta: R 4.4

  As mensagens de erro devem mostrar os passos concretos para a resolução dos mesmos.
  – ver requisito 4.4 na lista Transação

  Evidências
  As mensagens de erro apresentadas nos campos do formulário Nova Ocorrência não fornecem informação suficiente para que o utilizador compreenda a causa do erro nem os passos necessários para o corrigir.

  Por exemplo, no campo Nome, quando são introduzidos caracteres numéricos, a mensagem apresentada é apenas "Campo inválido", sem indicar quais os valores permitidos.

  O sistema apresenta mensagens genéricas de validação (ex.: "Campo inválido"), e o utilizador não recebe informação sobre o motivo da validação ter falhado, nem são indicadas ações concretas para corrigir o erro.

  

  Figura 1 - Mensagens de erro do formulário Nova ocorrência

  Recomendações
  As mensagens de validação devem indicar claramente a regra que não foi cumprida e como corrigir o problema.
  Exemplos para a mensagem de erro no campo "Nome":

  • "O nome deve conter apenas letras."
  • "Não são permitidos números ou caracteres especiais neste campo."

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #63 Outras violações - Link "Aqui" com destino pouco claro

  etiqueta: NOKetiqueta: outras violações

  Evidências:
  Na página Que ocorrência posso submeter no Alerta Lobos, existe um link com texto "Aqui".

  Uma pessoa que navega com o leitor de ecrã através da lista de links ou ao navegar com Shift pelos elementos interativos, terá dificuldade em perceber o destino e função do link "Aqui".

  

  Figura 1 - Lista de links do NVDA apresenta o link "Aqui"

  Recomendações:
  Garantir que a função do link é suficientemente descritiva para que se perceber o destino sem o contexto restante da frase:
  "Por exemplo, no âmbito da gestão da água e resíduos sólidos, a competência no concelho de Câmara de Lobos é da ARM – Água e Resíduos da Madeira. Consulte os contactos da ARM – Água e Resíduos da Madeira."