Relatório Avaliação de Candidatura
Câmara Municipal de Celorico de Basto

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #52 Uso inapropriado de atributos no menu

  etiqueta: chk 10 webetiqueta: R 1.2etiqueta: NOK

  O atributo aria-haspopup é utilizado na construção de menus do tipo aplicação. No entanto, o menu principal do website corresponde a um menu de navegação por links, pelo que não devem recorrer a este atributo:

  

  URLs

  • https://www.mun-celoricodebasto.pt/viver/ambiente-e-recursos-naturais/ - menu principal

  Sugestão de correção

  • Devem verificar no menu desktop e nas versões mobile/tablet.
  • Remover esse atributo do menu, uma vez que se trata de uma menu de navegação e não de aplicação.

• evidência: issue #51 Não é possível distinguir o menu principal de outras navegações

  etiqueta: chk 10 webetiqueta: R 1.2etiqueta: NOK

  Quando navegamos com o leitor de ecrã, é possível identificar quatro navegações identificadas como “Menu”, o que impossibilita distinguir entre o menu principal e as restantes opções:

  

  URLs

  • https://www.mun-celoricodebasto.pt/

  Sugestão de correção

  • Nomear adequadamente cada navegação nav, para isso devem alterar o aria-label="Menu" por um nome que permita identificar claramente a função de cada área de navegação. Por exemplo: aria-label="Menu principal", aria-label="Acesso rápido", aria-label="Políticas e Conformidade" e aria-label="Atalhos".

• evidência: issue #50 Não é possível aceder as subopções com o leitor de ecrã e teclado

  etiqueta: chk 10 webetiqueta: R 1.2etiqueta: NOK

  No menu lateral, quando se navega com o leitor de ecrã utilizando as setas direcionais (VO + ← →), não é possível abrir as subopções do menu lateral. Isto acontece porque o botão de expandir está estruturado dentro do próprio link. Como resultado, o leitor de ecrã anuncia simultaneamente a opção “Serviços ao cidadão” e o botão de expandir “Open menu”. Quando o utilizador seleciona esta opção, é acionado diretamente o link da página, impedindo o acesso às subopções do menu:

  

  Leitor de ecrã anuncia o link para a página "Serviços ao cidadão" e o botão “Open menu” como sendo o mesmo elemento interativo

  Para além disso, o botão de expandir está estruturado de forma inapropriada. O atributo role="button" está dentro da tag svg:

  

  Botão de abrir e fechar subopções estruturados como botão de forma inapropriada

  ---

  Outro exemplo acontece quando navegamos com o leitor de ecrã no menu principal na versão mobile/tablet. Não é possível identificar quais opções contém subopções, pois não é indicado se elas estão abertas ou fechadas. Para além disso, ao abrir uma opção de 1º nível com o teclado, as subopções não se mantém abertas. Com o leitor de ecrã, embora fiquem visíveis ele "salta" e navega apenas nas opções de primeiro nível:

  

  URLs

  • https://www.mun-celoricodebasto.pt/servicos/

  Sugestão de correção

  • Analisarem o menu desktop e nas versões mobile/tablet.
  • Devem separar o link de navegação da página interna e do botão de abrir/fechar as subopções.
  • O elemento que abre e fecha as subopções deve ser um botão ▾. Caso optem em utilizar a sinalética ▾ para o botão, devem garantir que tenha um nome acessível apropriado, como por exemplo: "Abrir subopção de Serviços do cidadão".
  • Devem utilizar o atributo aria-expanded apropriadamente para que os leitores de ecrã identifiquem se a opção está aberta ou fechada.
  • O acesso as páginas internas deve ser feito através de um link a.
  • Para mais informações partilhamos um exemplo de menu flyout da W3C: https://www.w3.org/WAI/tutorials/menus/flyout/#use-button-as-toggle

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #81 A sinalética visual que indica subopções não possui um texto alternativo apropriado

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.3

  Para além do SVG não estar estruturado de forma correta, verifica‑se que, no menu lateral, a sinalética visual ▾ possui texto alternativo em inglês — “Open menu section”:

  

  URLs

  • https://www.mun-celoricodebasto.pt/

  Sugestão de correção

  • Devem garantir a correta construção do menu. Por isso, recomendamos analisarem em conjunto com a issue #50.
  • O elemento que abre e fecha as subopções deve ser um botão ▾. Caso optem em manter a sinalética ▾ para o botão, devem garantir que tenha um nome acessível apropriado, como por exemplo: "Fechar subopções de Câmara Municipal".

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

Lista de evidências recolhidas:

• evidência: issue #5 Na homepage o logo não está marcado como h1

  etiqueta: chk 10 webetiqueta: R 2.1etiqueta: melhoria

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

  • Ver requisito 2.1 da lista 10 aspetos

  Nas homepage não existe um cabeçalho h1 marcado no logótipo. Cada página deve conter um cabeçalho de nível um (h1) para dar aos utilizadores de leitores de ecrã um ponto de referência fiável que lhes permita saltar diretamente para o conteúdo principal. Além disso, na homepage, o h1 deve estar atribuído ao logótipo para, em conjunto com um texto alternativo correto, melhorar o SEO da página.

  Evidencias:

  

  Figura 1 - Logo da página marcado apenas com <div> e <a>.

  URLs a verificar:

  https://www.mun-celoricodebasto.pt/

  Recomendações:

  • Na homepage, o h1 deve estar atribuído ao logótipo para, em conjunto com um texto alternativo correto, melhorar o SEO da página.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #75 Incorreta marcação de cabeçalhos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

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

  Verifica-se a ausência de uma estrutura consistente de cabeçalhos em várias páginas do website. Foram identificadas as seguintes situações:

  • Existência de secções relevantes sem qualquer marcação semântica de cabeçalho.
  • Utilização incorreta de elementos <p> para representar títulos de secções.
  • Ausência de cabeçalhos descritivos em componentes interativos, nomeadamente acordeões.
  • Inconsistência na marcação de títulos em listas de conteúdos, como notícias e páginas relacionadas.

  Estas práticas comprometem a compreensão da estrutura da página por tecnologias de apoio, dificultando a navegação e interpretação dos conteúdos.

  Evidencias:

  

  Figura 1 - Cabeçalhos em falta, com sugestão a vermelho do que pode ser adicionado na página inicial do website.

  

  Figura 2 - Falta de cabeçalhos na página; os acordeões devem ter um cabeçalho descritivo.

  

  Figura 3 - O campo "Páginas relacionadas", em todos os URLs do website, deve ser alterado para cabeçalho em vez de <p> .

  

  Figura 4 - O campo "Notícias relacionadas", em todos os URLs do website, deve ser alterado para cabeçalho em vez de <p> .

  

  Figura 4 - O título de cada notícia está marcado com <p> em vez de um cabeçalho.

  

  Figura 5 - Cabeçalho das notícias na homepage marcado com p

  URLs a verificar:
  https://www.mun-celoricodebasto.pt/ (verificar todas as páginas quanto à falta de cabeçalhos)
  https://www.mun-celoricodebasto.pt/municipio/mensagem-do-presidente/
  https://www.mun-celoricodebasto.pt/viver/investir/
  https://www.mun-celoricodebasto.pt/noticias/

  Recomendações:

  • Necessário rever todas as páginas do website.
  • Adicionar os cabeçalhos em falta, conforme sugerido nas imagens das evidências. Na página inicial, o título "Notícias em destaque" pode ser oculto visualmente mas acessível para os leitores de ecrã. Para mais informações consultar: https://www.acessibilidade.gov.pt/tutorial/css-em-accao-conteudo-invisivel-apenas-para-utilizadores-de-leitor-de-ecra/#page1_topic_2
  • O título dos acordeões devem ser estruturados como cabeçalhos. É necessário garantir que não exista saltos na hierarquia dos cabeçalhos, como por exemplo do h3 para o h5. Essa análise deve ser feita em todos os acordeões do website.
  • As secções "Páginas relacionadas" e "Notícias relacionadas", em todos os URLs do website, devem ser alteradas para cabeçalhos em vez de <p>.
  • O título de cada notícia na página de notícias deve ser alterado para um cabeçalho em vez de <p> .

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #68 Tabelas de dados sem caption

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 3.2

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

  Verifica-se a falta de existência do elemento caption com uma legenda descritiva do seu conteúdo na tabela.

  Evidências:

  

  URL:
  https://www.mun-celoricodebasto.pt/municipio/glossario/

  Recomendações:

  • Adicionar o elemento <caption> à tabela com uma legenda descritiva do seu conteúdo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #80 Etiquetas posicionadas de forma incorreta

  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

  Existem etiquetas associadas a caixas de texto que estão posicionadas estruturalmente a seguir a essas caixas de texto:

  

  Etiquetas posicionadas a seguir às caixas de texto
  Como se pode observar na figura, as etiquetas “Endereço”, “Localidade” e “Código postal” do formulário Participe no futuro PDM encontram-se posicionada a seguir às caixas de texto a que estão associadas, o que pode confundir os utilizadores de leitores de ecrã ao navegarem como o cursor virtual, pois as caixas de texto são anunciadas antes das etiquetas.
  Relativamente a controlos como caixas de verificação e botões de rádio,
  É comum que as etiquetas sejam posicionadas a seguir a esses campos, mas quando tratamos de outros controlos de formulário, tais como caixas de texto ou caixas combinadas, as etiquetas costumam ser posicionadas antes destes (https://www.w3.org/WAI/tutorials/forms/labels/).
  Recomendamos que todas as etiquetas associadas a caixas de texto sejam posicionadas antes dos campos a que estão associadas.

• evidência: issue #69 Existem etiquetas associadas a elementos que não são campos

  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

  A etiqueta “Autenticação” do formulário da página Onde ficar está associada a um elemento <div>:

  

  Etiqueta associada a um elemento que não é campo de formulário
  Recomendamos a remoção desta etiqueta, pois constitui-se como ruído no formulário, passando a informação de um campo que não existe nesta página.

• evidência: issue #55 Existem agrupamentos de controlos não envolvidos em elementos `<fieldset>`

  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

  Os grupos de radio buttons do formulário “Inquérito aos HABITANTES” da página Inquéritos de Satisfação não estão envolvidos em elementos <fieldset>:

  

  Etiqueta incorretamente aplicada ao grupo de radio buttons
  Como se pode observar na figura, os radio buttons “Muito satisfeito”, “Satisfeito”, “Normal”, “Insatisfeito” e “Muito insatisfeito” estão associadas à legenda “Como avalia a gestão de resíduos no município?”. No entanto, essa associação não existe semanticamente.
  Para que tal aconteça, os botões de rádio devem ser colocadas dentro de um elemento <fieldset>, elemento esse que deve ter como primeiro filho um elemento <legend> contendo o texto “Como avalia a gestão de resíduos no município?”, da seguinte forma:

  <fieldset>
    <legend>Como avalia a gestão de resíduos no município? <<<indicação de preenchimento obrigatório>>></legend>
    <input id = " rrb1 " type = "radio">
    <label for = "rb11">Muito satisfeito</label>
    <input id = "rb2" type = "radio">
    <label for = "rb2">Satisfeito</label>
    <input id = "rb3" type = "radio">
    <label for = "rb3">Normal</label>
  ...
  </fieldset>
  

  Desta forma, ao navergarmos com o teclado pelos botões de rádio, os leitores de ecrã anunciam, para além do texto do elemento associado a cada um deles, o texto do elemento

  que é a razão de ser do agrupamento dos radio buttons, transmitindo assim um maior contexto acerca da função destes campos.
  Fazemos notar que, tal como está, o elemento com o texto “Como avalia a gestão de resíduos no município?” não tem utilidade, pois não está associado semanticamente a nenhum campo.
  O mesmo problema acontece também nas seguintes situações:

  • Nos restantes agrupamentos de radio buttons do mesmo formulário;
  • nos agrupamentos de radio buttons e de checkboxes presentes no formulário “Inquérito aos TURISTAS” da mesma página;
  • Nos agrupamentos (entre os quais as textboxes relativas à morada) presentes no formulário “Adicionar um estabelecimento à lista” presente na página Onde ficar;
  • Nos agrupamentos presentes no formulário da página PAPERSU 2030;
  • Nos agrupamentos presentes no formulário da página Participe no futuro PDM.

  Recomendamos que agrupamentos de controlos relacionados sejam colocados dentro de elementos <fieldset>, e os elementos <label> de catalogação de cada grupo sejam substituídos por elementos <legend> colocados dentro do elemento <fieldset>, conforme apresentado acima.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #66 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

  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 no início do formulário.

  No formulário da página PAPERSU 2030 não existe informação sobre o significado do asterisco no campo de preenchimento obrigatório “Li e aceito a Política de Privacidade da Câmara Municipal de Celorico de Basto”.

  Recomendamos a revisão dos formulários por forma a adicionarem uma legenda no início do formulário que indique claramente o significado de . Por exemplo, “ Campos de preenchimento obrigatório”.

  Recomendamos que seja usado apenas “(obrigatório)” ou “(campo obrigatório)” à frente dos rótulos dos campos, ou em alternativa o uso do * (desde que a indicação do seu significado conste no topo do formulário).

  

  Figura 1 - Formulário da página PAPERSU 2030. Não existe informação sobre o significado do asterisco no campo de preenchimento obrigatório “Li e aceito a Política de Privacidade da Câmara Municipal de Celorico de Basto”.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #77 Existem formulários sem Mensagens de erro junto aos campos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.3

  É possível localizar e ler as mensagens de erro usando apenas um leitor de ecrã.
  – ver requisito 4.3 na lista 10 aspetos

  Os campos “Endereço” e “Localidade” do formulário Onde ficar não apresenta mensagens de erro na sua vizinhança:

  

  Campos endereço e localidade do formulário da página Onde ficar sem mensagens de erro na vizinhança
  Na vizinhança do campo “Código postal” existe uma mensagem de erro que refere os três campos do agrupamento morada e está programaticamente associada a eles, pelo que os leitores de ecrã anunciam essa mensagem ao navegar por teclado (tab e shift+tab).
  No entanto, ao navegar pelo formulário utilizando o modo de navegação dos leitores de ecrã, a mensagem de erro só é anunciada após ser lido o campo “Código postal”.

  Recomendamos que sejam apresentadas mensagens de erro junto aos campos de todos os formulários, para que sejam anunciadas individualmente pelos leitores de ecrã a seguir à leitura de cada campo, independentemente do modo de navegação utilizado. Assim, a mensagem que abrange os três campos do agrupamento morada deve ser dividida em três mensagens individuais, uma para cada campo deste agrupamento.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #72 Imagens não decorativas sem texto alternativo associado

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

  Evidências:

  O ícone de alerta apresenta alt inadequado (“ícone”), não acrescentando informação útil e introduzindo redundância face ao texto adjacente. Deve ser tratado como decorativo (alt="").

  

  ---

  Verifica-se que a imagem dos logótipos de cofinanciamento apresenta texto alternativo (alt), no entanto a descrição fornecida é genérica e insuficiente, não permitindo identificar quais os logótipos efetivamente representados. Nesse caso o alt deve descrever corretamente a imagem apresentada, por exemplo: alt="Logótipos de cofinanciamento: Norte 2030, Portugal 2030 e União Europeia"

  

  URL:

  https://www.mun-celoricodebasto.pt/viver/educacao-e-formacao/ensino-superior/

  Recomendações:

  • As imagens não decorativas deverão ter uma descrição breve associada, nomeadamente através do uso do atributo descrevendo corretamente a imagem apresentada. Por exemplo, no ícone de alerta o texto alternativo poderá ser: alt="Alerta".

• evidência: issue #10 (Melhoria) Imagens decorativas com texto alternativo indevido

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 5.1

  Evidências:
  Verifica-se que algumas imagens funcionam apenas como apoio visual, encontrando-se a informação relevante já disponibilizada através de título, descrição e links acessíveis em texto. Nestes casos, as imagens podem ser tratadas como decorativas, devendo possuir alt="".

  Um exemplo são os cards da secção "Outras Noticias" na homepage, não acrescentam informação relevante ou adicional ao conteúdo textual já disponibilizado (título e descrição do evento). No entanto, estas imagens estão a ser expostas aos leitores de ecrã através de texto alternativo preenchido.

  

  ---

  O mesmo ocorre com as imagems dos botões da sessão "Atalhos", o destino/opção já se encontrar identificado no texto visível do próprio cartão. Neste contexto, a imagem assume função meramente decorativa e não deveria introduzir informação adicional através do atributo alt.

  

  ---

  O ícone de alerta apresenta alt inadequado (“ícone”), não acrescentando informação útil e introduzindo redundância face ao texto adjacente. Deve ser tratado como decorativo (alt="").

  

  URL:
  (deve ser validado em todo o site)
  https://www.mun-celoricodebasto.pt/
  https://www.mun-celoricodebasto.pt/municipio/mensagem-do-presidente/
  https://www.mun-celoricodebasto.pt/municipio/camara-municipal/
  https://www.mun-celoricodebasto.pt/municipio/camara-municipal/executivo-municipal/
  https://www.mun-celoricodebasto.pt/municipio/breve-historia-do-concelho/
  https://www.mun-celoricodebasto.pt/municipio/revista-municipal/
  https://www.mun-celoricodebasto.pt/municipio/assembleia-municipal/documentos/
  https://www.mun-celoricodebasto.pt/viver/educacao-e-formacao/ensino-superior/
  https://www.mun-celoricodebasto.pt/servicos/contactos-gerais/
  https://www.mun-celoricodebasto.pt/servicos/contratacao-publica/
  https://www.mun-celoricodebasto.pt/servicos/servicos-ao-cidadao/
  https://www.mun-celoricodebasto.pt/sustentabilidade/story-top100/
  https://www.mun-celoricodebasto.pt/visite-celorico/o-que-fazer/viver/

  Recomendações:

  • Recomenda-se que as imagens decorativas tenham alt="".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #46 Imagem não é acompanhado de uma descrição longa

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.2

  Evidências:

  No gráfico da página Constituição, deve-se substituir aria-describedby por aria-labelledby sempre que a informação associada corresponder ao título ou identificação principal do gráfico, assegurando uma implementação semanticamente correta.

  

  ---

  Verifica-se que algumas imagens com conteúdo visual complexo, não dispõem de uma descrição complementar associada através de aria-describedby, apesar de conterem informação textual associado ao conteúdo o texto não apresenta todas as informações relevantes contidas na imagem.

  

  ---

  Verifica-se que a imagem apresentada contém um gráfico "Peso da dívida na receita" e informação tabular relevante, mas esse conteúdo não está disponibilizado de forma acessível para utilizadores de tecnologias de apoio. A imagem surge com alt="", sendo tratada como decorativa, apesar de incluir dados informativos essenciais.

  Tratando-se de um gráfico, deve existir um mecanismo que permita aceder ao seu conteúdo em formato acessível, nomeadamente através de uma ligação para os dados do gráfico ou da disponibilização da tabela correspondente em HTML acessível.

  

  ---

  URL:
  https://www.mun-celoricodebasto.pt/eventos/feira-de-abril-4/
  https://www.mun-celoricodebasto.pt/agenda/ (validar todas as imagens da sessão Agenda)
  https://www.mun-celoricodebasto.pt/municipio-de-celorico-de-basto-reitera-compromisso-com-a-sustentabilidade-financeira/

  Recomendações:

  • Para o gráfico da página Constituição, substituir aria-describedby por aria-labelledby.
  • Para as imagens complexas recomenda-se adicionar o conteúdo relevante no texto associado à imagem ou via aria-describedby.

  Para o gráfico (Peso da dívida na receita):

  • Recomenda-se que os dados apresentados no gráfico sejam disponibilizados em formato acessível, para tal, deve ser inserida uma alternativa textual equivalente, preferencialmente através de uma tabela HTML acessível com os valores representados no gráfico, permitindo leitura e navegação por tecnologias de apoio.

  • Outra alternativa seria disponibilizar uma ligação associada ao gráfico para acesso direto aos dados ou à descrição detalhada do conteúdo apresentado. Como neste exemplo: https://www.w3.org/WAI/tutorials/images/complex/

  • Nestes casos, a imagem pode manter um alt breve identificativo, desde que a informação completa esteja acessível por meio da tabela ou do conteúdo textual associado.

• evidência: issue #14 Imagem/gráfico não acessível para tecnologias de apoio

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.2

  Evidências:

  Validado que não é possível navegar pelo mapa com recurso a leitor de ecrã, o que impede o acesso ao conteúdo interativo e à informação disponibilizada nas diferentes áreas do mapa.

  Validado também que a página já disponibiliza, em conteúdo textual acessível, a informação necessária para complementar a compreensão da imagem/mapa, incluindo a descrição do território e as instruções de utilização. Neste contexto, não se justifica a duplicação dessa informação utilizando o aria-describedby para que o mesmo texto seja lido pelos leitores de ecrã na imagem.

  

  ---

  URL:

  https://www.mun-celoricodebasto.pt/municipio/freguesias-do-concelho/
  https://www.mun-celoricodebasto.pt/municipio/assembleia-municipal/constituicao/

  Recomendações:

  • Recomenda-se remover a descrição extensa dos atributos "data-*".
  • Disponibilizar uma alternativa acessível ao mapa interativo, assegurando que a mesma informação e funcionalidades podem ser utilizadas por teclado e tecnologias de apoio. Para tal, deve ser criada uma estrutura HTML equivalente.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #3 Existem imagens link com texto alternativo incorreto

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

  Evidências:
  Verifica-se que a imagem do logótipo, utilizada como link para a página inicial, apresenta um texto alternativo que não descrevendo adequadamente o seu propósito (acesso à página inicial).

  

  Link de acesso à homepage com texto alternativo insuficiente

  ---

  Validado que a imagem link do site da Proteção Civil abre numa nova janela (target="_blank") porém não informa explicitamente o utilizador, o que pode causar desorientação, especialmente para utilizadores de tecnologias de apoio. Exemplo de descrição: alt="Serviço Municipal Proteção Civil de Celorico de Basto (abre numa nova janela)".

  

  Link de acesso à página da Proteção Civil com texto alternativo insuficiente

  ---

  Verifica-se que a imagem está a ser anunciada pelo leitor de ecrã através do nome do ficheiro (“Rede-Escolar-Celorico-de-Basto-1024x724.jpg”). O elemento interativo associado à imagem (link ou botão de ampliação) deve possuir um nome acessível claro e significativo no elemento alt, evitando que o leitor de ecrã utilize o nome do ficheiro como fallback. Por exemplo: alt=“Ampliar mapa da rede escolar do concelho de Celorico de Basto”.

  

  Imagem do mapa da rede de escolas apresenta texto alternativo incorreto

  ---

  Verifica-se que o link do ícone de partilha utiliza uma imagem/ícone inserido via CSS para comunicar a sua função. Quando os estilos são desativados, o ícone desaparece, deixando de ser possível perceber a finalidade do botão apenas com base no conteúdo disponível no código.

  

  Ícones de partilha inseridos via CSS

  O campo de pesquisa também esta a ser inserido via CSS:

  

  Imagem do campo de pesquisa onde é passível identificar que o elemento esta a ser inserido via CSS

  ---

  URL:
  https://www.mun-celoricodebasto.pt/municipio/assembleia-municipal/constituicao/
  https://www.mun-celoricodebasto.pt/servicos/protecao-civil/
  https://www.mun-celoricodebasto.pt/eventos/heart-run/
  https://www.mun-celoricodebasto.pt/ - campo de pesquisa

  Recomendações:

  • O texto alternativo deve transmitir claramente o destino ou finalidade do link. Por exemplo: alt="Câmara Municipal de Celorico de Basto– página inicial"
  • Recomenda-se que, sempre que uma imagem ou ícone seja inserido exclusivamente via CSS (como é o caso do Botão pesquisar e dos links de partilha), seja incluído um texto em HTML no interior do botão, por exemplo através de um elemento <span>, garantindo que a função do componente permanece disponível para tecnologias de apoio. Esse texto pode ficar visualmente oculto, mas deve continuar acessível a leitores de ecrã. Para mais informações: https://www.acessibilidade.gov.pt/tutorial/css-em-accao-conteudo-invisivel-apenas-para-utilizadores-de-leitor-de-ecra/#page1_topic_7

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #37 Texto normal não tem contraste suficiente

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 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.
  – ver requisito 6.1 na lista 10 aspetos

  
Notas gerais

  • O contraste no texto normal (menor que 18 pontos ou menor que 14 pontos negrito) das páginas deve ser, no mínimo 4,5:1, para que pessoas com baixa visão consigam ler o texto.

  A avaliação com a ferramenta Colour Contrast Analyser e ANDI revela problemas relacionados com insuficiência de contraste, afetando diretamente a legibilidade.

  O website apresenta problemas de contrastena página Participe no futuro PDM, pois utilizam a combinação de cores #767676(cor de primeiro plano) e #F4F4F4(cor de plano de fundo). (Figura 1)

  

  Figura 1- Texto do formulário com problemas de contraste

  O mesmo problema acontece no modo escuro. Na combinação de cores #9F968799(cor de primeiro plano) e #292B2B(cor de plano de fundo) (Figura 2)

  

  Figura 2- Problemas de contraste no modo escuro

  Há problemas de contrastes na interação com a componente dos acordeões. Por exemplo na página Feiras, Festas e Romarias a combinação de cores #FFFFFF(cor de primeiro plano) e #4CAF50(cor de plano de fundo) não passa na avaliação de contraste para texto normal. (Figura 3)

  

  Figura3- Interações de acordeões com taxa de contraste inferior ao recomendado

  Recomendações
  Recomendamos a revisão de todo website, incluindo no modo escuro para garantir a taxa de contraste mínima recomendada nas combinações de cores utilizadas em texto normal, incluindo estados de foco e hover.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #38 Textos grandes tem contraste suficiente no website

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 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.
  – ver requisito 6.2 na lista 10 aspetos

  Notas Gerais

  • 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, para que as pessoas com baixa visão consigam ler o texto.

  Apesar de a maioria dos textos de grande dimensão do website não apresentar problemas de contraste, foi identificado um problema específico na modal de pesquisa da página inicial. Os títulos associados aos resultados de pesquisa, com tamanho aproximado de 20px, não se encontram visíveis, uma vez que camadas de CSS sobrepostas ocultam a cor do texto, comprometendo a sua legibilidade (Figura 1).

  

  Figura 1 - Texto grande da "Pesquisa" na página inicial não é visível”

  A problemática está isolada à implementação da modal de pesquisa na página inicial, pois este comportamento não se verifica nas páginas interiores do website, onde os mesmos textos são corretamente apresentados e cumprem os requisitos de contraste exigidos (Figura 2).

  

  Figura 2 - Texto grande da "Pesquisa" nas páginas interiores são visíveis”

  Recomendação:
  É necessário analisar e corrigir a estrutura de camadas (z-index, opacidade, fundos ou pseudo-elementos) aplicada na modal de pesquisa da página inicial, removendo ou ajustando os elementos CSS que estão a ocultar o texto. Deve ainda ser garantido que a cor do texto apresenta contraste suficiente face ao fundo, assegurando a legibilidade dos títulos de resultados e a conformidade com os requisitos de acessibilidade aplicáveis.

  Outras evidências (OK):

  • https://www.mun-celoricodebasto.pt/
  • https://www.mun-celoricodebasto.pt/viver/investir/
  • https://www.mun-celoricodebasto.pt/viver/
  • https://www.mun-celoricodebasto.pt/servicos/documentos/
  • https://www.mun-celoricodebasto.pt/campo-da-feira-de-gandarela-de-basto-em-celorico-de-basto-requalificado/

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #58 Deve ser possível ativar os botões de controlo do leitor quer com o rato quer com o teclado

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 7.1

  Evidências:
  Verifica-se que os controlos do player multimédia são acessíveis e podem ser alcançados por teclado ou tecnologias de apoio, no entanto não permanecem visíveis durante a reprodução do vídeo.

  Tal como ilustrado no exemplo, enquanto o conteúdo está a ser apresentado, os controlos deixam de estar permanentemente expostos no ecrã, o que dificulta a sua identificação, localização e utilização por parte dos utilizadores. Ao navegar com Tab e leitor de ecrã, o foco não regressa de forma consistente ao comando anteriormente utilizado. Em várias situações, em vez de retornar ao controlo esperado, o foco é reposicionado no topo ou na área geral do vídeo, comprometendo a continuidade da navegação e a compreensão do contexto atual.

  

  URL:
  https://www.mun-celoricodebasto.pt/municipio/assembleia-municipal/reunioes-da-assembleia/

  Recomendações:

  • É necessário garantir que os controles do vídeo sejam apresentado quando acionamos com a teclas tab ou shift+tab, além de ter o indicador de foco visível, assegurando que o utilizador consegue identificar claramente a ação disponível.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #61 Os players não têm legendas audiodescritivas

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 7.2

  Evidências:
  Alguns players não têm legendas, os restantes players no website usam as legendas automáticas do youtube, é recomendado que estas sejam substituídas por uma legenda fechada.

  

  URL:

  https://www.mun-celoricodebasto.pt/municipio/assembleia-municipal/reunioes-da-assembleia/
  https://www.mun-celoricodebasto.pt/visite-celorico/capital-das-camelias/
  https://www.mun-celoricodebasto.pt/visite-celorico/desporto-e-lazer/ecopista/

  Recomendações:
  Recomendamos que seja incluído uma legenda para cada vídeo, caso a legenda gerada automaticamente esteja boa ela pode ser reaproveitada para gerar uma nova transcrição do conteúdo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #87 Existem cards estruturados de forma inapropriada

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

  Quando se navega com o leitor de ecrã nos cards do website, todos os elementos que compõem o card são anunciados ao mesmo tempo: o texto alternativo da imagem, a categoria e a data, o título — que, neste caso, é igual ao texto alternativo da imagem — e o texto descritivo. Esta leitura torna‑se excessivamente longa e repetitiva, além de apresentar informação redundante.

  

  Leitor de ecrã anuncia todos os elementos do card de uma só vez

  Isto acontece porque todos os elementos do card estão colocados dentro do mesmo link a. Quando um leitor de ecrã encontra um link que contém múltiplos elementos, ele lê todo o conteúdo interno como parte do mesmo elemento clicável.

  

  URLs

  • https://www.mun-celoricodebasto.pt/noticias/

  Sugestão de correção

  • Separar estruturalmente os elementos do card do link. O link deve envolver apenas o título principal da notícia, evitando que o leitor de ecrã leia todo o card como um único bloco.
  • Estruturar os títulos dos cards como cabeçalhos.
  • Estender a área clicável do card para todo o seu conteúdo. Para isso, recomendamos utilizarem uma abordagem semelhante ao Streched link do Bootstrap.

• evidência: issue #53 Acordeões não estão agrupados como lista

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Notas Gerais

  • Quando agrupamos os acordeões dentro de uma lista, estamos a fornecer informações estruturais relevantes ao utilizador. Esta organização permite que o leitor de ecrã anuncie, por exemplo, quantas opções existem no conjunto e que todos os itens pertencem ao mesmo grupo. Além disso, ajuda o utilizador a perceber que o conteúdo apresentado está relacionado entre si.

  URL a verificar

  • https://www.mun-celoricodebasto.pt/transparencia/
  • https://www.mun-celoricodebasto.pt/viver/investir/localizacao-e-acessibilidades/#como-chegar
  • (outras páginas com listagens de conteúdos em acordeões)

  Evidências:

  Existem páginas que apresentam conteúdos em formato de acordeão; no entanto, apesar de serem informações relacionadas entre si, estes elementos não estão estruturados semanticamente como uma lista ul li:

  

  Figura 1 – Conteúdo em acordeão estruturado com elementos não semânticos (<div>/<p>) sem utilização de listas (<ul>/<li>) para representar conjuntos de itens

  Este padrão repete-se em várias áreas do website, indicando um problema transversal na estrutura semântica desse componente.

  Recomendações:

  • Recomenda-se os acordeões sejam estruturados utilizando elementos semânticos apropriados, nomeadamente listas (<ul> ou <ol>), onde cada item é representado por um <li>.
  • Para orientação sobre boas práticas na estruturação semântica de conteúdos, recomenda-se a consulta da documentação do W3C: https://www.w3.org/WAI/tutorials/page-structure/content/#lists
  • Adicionalmente, recomenda-se a revisão deste padrão em todo o website, uma vez que este tipo de componente (acordeões/listagens) tende a ser reutilizado em várias páginas. Deve ser validado com leitores de ecrã para garantir que o agrupamento e a navegação entre itens são corretamente comunicados.

• evidência: issue #42 Uso inadequado do `role="list"` na estrutura de cards em listagens de conteúdo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Notas Gerais

  • O papel ARIA role="list" deve ser utilizado para identificar um conjunto de elementos que representam uma lista semântica, sendo esperado que os seus elementos filhos tenham o papel role="listitem" ou que exista uma estrutura equivalente que transmita corretamente a relação de lista às tecnologias de apoio. A utilização incorreta deste papel pode levar a interpretações erradas por leitores de ecrã, comprometendo a compreensão da estrutura da página.

  URL a verificar

  • https://www.mun-celoricodebasto.pt/noticias/
  • https://www.mun-celoricodebasto.pt/

  Evidências:

  Nas páginas indicadas, os conjuntos de cards de notícias são implementados com um contentor que utiliza role="list". No entanto, os elementos filhos (cards individuais) não utilizam role="listitem" nem correspondem a elementos semânticos de lista (como <li> dentro de <ul> ou <ol>). Em vez disso, são construídos com <div> e outros elementos genéricos, sem uma associação semântica adequada.

  

  Figura 1 – Contentor com role="list" aplicado a um conjunto de cards sem elementos listitem associados

  Como consequência, as tecnologias de apoio podem anunciar a existência de uma lista, mas não conseguem identificar corretamente os seus itens, o que resulta numa experiência inconsistente ou confusa para utilizadores de leitores de ecrã. Esta discrepância entre o papel atribuído e a estrutura real viola as boas práticas de utilização de ARIA, nomeadamente o princípio de não usar ARIA quando a semântica nativa não está corretamente assegurada.

  Recomendações:

  Recomenda-se a revisão da implementação destes componentes, garantindo que a semântica da lista é corretamente aplicada. Caso o objetivo seja representar uma lista de conteúdos, deve ser utilizada marcação HTML nativa com <ul> ou <ol> e respetivos <li>.

  Caso os elementos não representem efetivamente uma lista, deve ser removido o atributo role="list" para evitar interpretações incorretas por parte das tecnologias de apoio. Recomenda-se ainda a validação com leitores de ecrã para confirmar que a estrutura é corretamente anunciada e compreendida.

• evidência: issue #41 Botões implementados com elementos semânticos inadequados

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 8.3

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

  Notas Gerais

  • Elementos interativos como botões devem ser implementados com elementos HTML semânticos apropriados, como <button>, de forma a garantir que são corretamente interpretados por tecnologias de apoio e suportam navegação por teclado.
    A utilização de elementos <a> deve ser reservada para navegação entre páginas. Quando usados para ações (ex.: abrir/fechar modais), podem introduzir ambiguidades na interpretação do seu propósito.

  URL a verificar

  • https://www.mun-celoricodebasto.pt/municipio/camara-municipal/executivo-municipal/ (modais-enviar mensagem)

  Evidências:

  No componente de modal, o botão de fechar é implementado através de um elemento <a>.
  Apesar de visualmente funcionar como botão, este elemento:

  • É semanticamente um link (<a>) e não um botão
  • Utiliza href para acionar uma ação (fechar modal), e não para navegação
  • Pode introduzir ambiguidades na interpretação do seu propósito por tecnologias de apoio
    Adicionalmente, o nome acessível do controlo é assegurado através do atributo title, o que não é recomendado como única forma de fornecer informação acessível.

  

  Figura 1 – Controlo de fechar do modal implementado como <a> e com nome acessível dependente do atributo title

  Recomendações:

  • Sempre que possível, utilizar elementos HTML nativos apropriados para ações, nomeadamente <button>, garantindo semântica correta e comportamento consistente.
  • Garantir suporte completo à navegação por teclado (Tab, Enter e Espaço) e correta interpretação por tecnologias de apoio.
  • Recomenda-se a verificação deste padrão em todo o website, uma vez que existem outros elementos interativos implementados como <a> ou <div> que desempenham funções de botão e que devem ser analisados e, sempre que possível, normalizados.

• evidência: issue #27 Modais construídas com `<div>` sem nome acessível atribuído

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Notas Gerais

  • As janelas modais devem possuir uma estrutura semântica adequada e um nome acessível programaticamente determinável, de forma a permitir que as tecnologias de apoio identifiquem corretamente o contexto apresentado ao utilizador. A ausência de um nome acessível pode dificultar a compreensão do conteúdo e da finalidade da modal.

  URL a verificar

  • https://www.mun-celoricodebasto.pt/municipio/camara-municipal/executivo-municipal/ (enviar mensagem)
  • https://www.mun-celoricodebasto.pt/ - modal apresentada no início do website e a de cookies
  • (entre outras páginas com modais)

  Evidências:

  As modais identificadas (por exemplo, formulário “Enviar mensagem” pesquisa e carousel de imagens) são construídas recorrendo maioritariamente a elementos genéricos como <div>, sem utilização de atributos ARIA apropriados, como role="dialog".

  Adicionalmente, estas modais não possuem um nome acessível associado (por exemplo através de aria-labelledby), o que impede que os leitores de ecrã anunciem corretamente o contexto da janela modal ao utilizador.

  

  Figura 1 – Modal construída com <div> sem papel semântico e sem nome acessível

  Recomendações:

  Recomenda-se que as modais sejam implementadas com uma estrutura acessível, incluindo a definição de role="dialog" (ou alertdialog, quando aplicável).
  O conteúdo da modal deve ser visível para as tecnologias de apoio apenas quando aberta, e para isso recomendamos gerenciar a visibilidade da modal utilizando o JavaScript + o atributo aria-modal ou aria-hidden, de forma a indicar corretamente o contexto de diálogo.

  Deve também ser garantido que cada modal possui um nome acessível, através da associação a um título visível com aria-labelledby ou, em alternativa, através de aria-label.

  Adicionalmente, recomenda-se assegurar a correta gestão de foco, incluindo foco inicial no primeiro elemento interativo da modal, confinamento do foco no interior da modal e retorno ao elemento de origem após o fecho. Recomenda-se ainda validação com navegação por teclado e leitores de ecrã para garantir uma experiência acessível.

• evidência: issue #26 Componente de feedback (reação/satisfação) não segue padrão acessível adequado

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Notas Gerais

  • Componentes de recolha de feedback, como classificações ou níveis de satisfação, devem ser estruturados de forma semântica e acessível, permitindo que tecnologias de apoio compreendam corretamente o seu propósito, estado e modo de interação.
  • Embora visualmente possam assumir a forma de botões, estes componentes representam frequentemente uma escolha única entre várias opções (semelhante a um grupo de botões de rádio). Nestes casos, é importante garantir que a estrutura, papéis ARIA e estados refletem esse comportamento.
  • A utilização inadequada de atributos como aria-pressed pode induzir interpretações erradas por parte de leitores de ecrã, comprometendo a experiência do utilizador.

  URL a verificar

  • https://www.mun-celoricodebasto.pt/municipio/mensagem-do-presidente/
  • (em quase todas as páginas do website)

  Evidências:

  O componente de feedback é apresentado como um conjunto de opções (“Insatisfeito”, “Parcialmente satisfeito”, “Satisfeito”, “Muito satisfeito”), mas está implementado com elementos <div> com role="button" e aria-pressed.

  No entanto:

  • O comportamento permite apenas uma única seleção, o que corresponde semanticamente a um grupo de botões de rádio, não a botões de alternância;
  • É utilizado aria-pressed, que é apropriado para botões toggle (on/off), mas não para seleção exclusiva;
  • Não é utilizado aria-checked, que seria o estado correto neste tipo de componente;
  • Os elementos não estão agrupados por um
    e

    .
  • Não existem elementos nativos <input type="radio"> nem <label> associados;
  • A navegação por teclado esperada (uso de setas dentro do grupo) não está garantida;
  • A estrutura baseada em <div> compromete a semântica e o comportamento esperado.

  

  Figura 1 – Componente de feedback implementado com <div role="button"> e aria-pressed, apesar de permitir apenas seleção única

  Recomendações:

  • Implementar o componente como um grupo de botões de rádio:
    • Utilizar <input type="radio"> com <label> associado
    • Agrupar as opções com o fieldset e utilizar o legend para dar contexto ao utilizador
  • Garantir que apenas uma opção pode estar selecionada de cada vez
  • Assegurar navegação por teclado adequada (setas entre opções)
  • Validar com leitores de ecrã para confirmar que o estado e o comportamento são corretamente anunciados

• evidência: issue #25 Campo de pesquisa estruturado de forma inapropriada

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  O campo de pesquisa é corretamente implementado como um <input type="search">. No entanto, verifica‑se que o atributo role="combobox" está a ser aplicado ao mesmo elemento. Este atributo altera a semântica nativa do campo, fazendo com que as tecnologias de apoio o interpretem como um campo de seleção (combobox), o que não corresponde à sua função de campo de pesquisa.

  Para além disso, estão a ser utilizados atributos inapropriados, como aria-haspopup. Este atributo é destinado a componentes interativos em widgets de aplicação — para indicar que o elemento abre um conteúdo adicional.

  No entanto, no campo de pesquisa, o aria-haspopup não tem qualquer função válida e acaba por transmitir às tecnologias de apoio a ideia de que o campo abre um menu ou componente associado, o que não acontece.

  

  URL a verificar

  • https://www.mun-celoricodebasto.pt/ - campo de pesquisa

  Sugestão de correção

  • Para garantir que o campo de busca seja anunciado corretamente para utilizadores de leitores de ecrã, é necessário remover os atributos aria-haspopup , role="combobox" e o aria-expanded.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #22 Conteúdo do slider de notícias não é apresentado sem CSS

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.4

  Quando se retira o CSS, a informação relevante permanece visível.
  – ver requisito 8.4 na lista 10 aspetos

  Notas Gerais

  • A informação e funcionalidade de uma página devem manter-se disponíveis independentemente da apresentação visual. Quando os estilos CSS são desativados, o conteúdo deve continuar acessível e compreensível, garantindo que não depende exclusivamente de componentes visuais ou comportamentos dinâmicos.

  URL a verificar

  • https://www.mun-celoricodebasto.pt/

  Evidências:

  Ao desativar o CSS, verifica-se que o conteúdo do slider (notícias na homepage) não é totalmente apresentado.

  Isto indica que o acesso ao conteúdo depende do funcionamento visual do componente (slider), comprometendo a sua disponibilidade quando os estilos não estão ativos.

  

  Figura 1 – Conteúdo do slider não totalmente visível após desativação de CSS

  Recomendações:

  • Garantir que todo o conteúdo do slider está presente no HTML e visível sem CSS
  • Evitar dependência de componentes dinâmicos para acesso à informação
  • Assegurar uma estrutura linear onde todos os itens são apresentados sequencialmente
  • Validar o comportamento da página com CSS desativado

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #17 Não existem conteúdos com layout organizado em elementos de tabela

  etiqueta: chk 10 webetiqueta: N/Aetiqueta: 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:
  Não foram identificados conteúdos que estão utilizando elementos de tabela para fins de layout ou apenas para apresentação e estilização. Sendo assim, o critério está a cumprir.

  Recomendações:
  N/A

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #15 (Melhoria) Quando a caixa de diálogo é aberta, não move-se para o primeiro elemento interativo dentro da caixa de diálogo

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 9.1

  Evidências:

  Quando a caixa de diálogo é ativada, o foco do navegador é colocado diretamente no campo de formulário, em vez de ser posicionado no primeiro elemento interativo da modal — o botão “Fechar”.

  

  URL:

  https://www.mun-celoricodebasto.pt

  Recomendações:

  • Quando a caixa de dialogo é aberta o foco deve ser posicionado no primeiro elemento interativo.

• evidência: issue #11 Modal inacessível a tecnologias de apoio

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.1

  Evidências:

  Verifica-se que a modal de cookies não se encontra acessível a tecnologias de apoio (teclado, leitor de ecrã). Ao ser apresentada, não é anunciada pelos leitores de ecrã e o foco não é direcionado para o conteúdo da modal.

  

  ---

  Verifica-se que a modal “Cookies settings”, quando aberta, não se encontra plenamente acessível a utilizadores de leitor de ecrã, teclado ou rato. O componente não garante uma interação funcional e percetível, comprometendo a navegação, a leitura do conteúdo e a utilização dos controlos disponíveis.

  Esta situação impede o acesso autónomo às definições de cookies e compromete a usabilidade do componente enquanto diálogo/modal.

  

  URL:

  https://www.mun-celoricodebasto.pt/

  Recomendações:

  • Deve ser garantido que, ao abrir a modal, o foco é automaticamente direcionado para o seu conteúdo, preferencialmente para o primeiro elemento interativo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #32 Foco não fica limitado a caixa de diálogo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.2

  Evidências:

  Verifica-se que quando a modal esta aberta o foco não fica limitado a modal (teclado, leitor de ecrã).

  

  URL:

  https://www.mun-celoricodebasto.pt/
  https://www.mun-celoricodebasto.pt/servicos/policia-municipal-de-celorico-de-basto/

  Recomendações:

  • Recomenda-se prender o foco do teclado dentro da dialog utilizando um script/evento no JavaScript ou na linguagem apropriada.
  • Quando o utilizador navega com TAB a partir do último elemento focável, o foco deve voltar para o primeiro elemento focável.
  • Quando o utilizador navega com SHIFT+TAB a partir do primeiro elemento focável, o foco deve mover‑se para o último elemento focável.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #82 A caixa de diálogo não pode ser encerrada através de tecnologias de apoio

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.3

  Evidências:

  Verifica‑se que a modal de cookies não está acessível às tecnologias de apoio, impedindo que a modal seja encerrada por leitor de ecrã ou teclado.

  

  URL:
  https://www.mun-celoricodebasto.pt/

  Recomendações:

  • A modal deve ser acessível por tecnologias de apoio (leitor de ecrã e teclado).

• evidência: issue #34 (Melhoria) A caixa dialogo não pode ser encerrada através da tecla ESC

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 9.3

  Evidências:

  Verifica‑se que a modal de Pesquisa não pode ser encerrada através da tecla ESC.

  

  ---

  Verifica‑se que a modal de cookies não possui um botão dedicado para fechar. Atualmente, para sair da modal é necessário acionar um dos botões “Não quero cookies”, “Compreendi e Aceito”, o que não é explícito tal como um botão de "Fechar".

  

  URL:

  https://www.mun-celoricodebasto.pt/
  https://www.mun-celoricodebasto.pt/servicos/policia-municipal-de-celorico-de-basto/

  Recomendações:

  • Idealmente podem implementar um mecanismo que permita o encerramento das janelas modais através da tecla ESC além do botão de fechar.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #18 Falta de resumo na página inicial do website

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.1

  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:

  Na página inicial do website da Municipal de Celorico de Basto, não aparece presente um resumo breve do próposito do site. Apesar de existir a frase "Site da Câmara Municipal de Celorico de Basto" na imagem no banner principal, esta frase não resume fielmente quais as tarefas ou a informação que é possível encontrar no website.

  O resumo deve estar disponível na parte superior da página inicial, sendo imediatamente visível sem necessidade de deslocamento (scroll). Embora atualmente se encontre no rodapé, é essencial que seja reposicionado para o topo da página, garantindo acesso direto e imediato ao seu conteúdo. No entanto, no rodapé para se manter a cumprir o critério 1.4 é necessário que em 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.

  

  Imagem da página inicial sem dar scroll.

  Recomendações:

  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 inicial, sem ser necessário fazer scroll, avançar no slideshow, entre outros.

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

  

  Image exemplo de uma frase de propósito do website acessibilidade.gov

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #23 Falta de termos complexos no glossário

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

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

  Evidências:

  Apesar de o website disponibilizar um glossário, foram identificados diversos termos técnicos e complexos ao longo do conteúdo que não possuem definição associada. A falta da definição compromete a compreensão da informação por parte dos utilizadores, especialmente aqueles com menor familiaridade com a terminologia utilizada.

  

  Imagem com o termo complexo GAP, disponível em: https://www.mun-celoricodebasto.pt/municipio/camara-municipal/executivo-municipal/

  

  Imagem com o termo complexo CACBAA, disponível em: https://www.mun-celoricodebasto.pt/servicos/servicos-ao-cidadao/balcao-unico-do-predio-bupi/

  

  Imagem com o termo complexo ADSE, disponível em: https://www.mun-celoricodebasto.pt/servicos/servicos-ao-cidadao/espacos-do-cidadao/

  Outros termos complexos encontrados:

  • IMI e IRS: https://www.mun-celoricodebasto.pt/servicos/financas-municipais-e-patrimonio/
  • CPCJ: https://www.mun-celoricodebasto.pt/municipio/camara-municipal/executivo-municipal/ na Nota Biográfica da Maria José Teixeira Marinho
  • PSD, PS, NÓS e Chega: https://www.mun-celoricodebasto.pt/municipio/assembleia-municipal/constituicao/
  • UF: https://www.mun-celoricodebasto.pt/municipio/freguesias-do-concelho/
  • DEE: https://www.mun-celoricodebasto.pt/viver/investir/newsletter-informadee/
  • IAPMEI: https://www.mun-celoricodebasto.pt/viver/investir/links-de-apoio/
  • LED: https://www.mun-celoricodebasto.pt/sustentabilidade/preservacao-ambiental/
  • AL, TER e TH: https://www.mun-celoricodebasto.pt/visite-celorico/onde-ficar/#cat-109-info

  Isto foram alguns exemplos encontrados pelo website, mas é necessário fazer uma revisão completa para que todos os termos complexos estejam com a sua definição no glossário.

  Recomendações:

  1. Expansão do glossário: Adicionar todos os termos técnicos, siglas e expressões específicas do domínio ao glossário existente, garantindo definições claras e concisas.

  2. Uso de linguagem simples: Sempre que possível, substituir termos complexos por linguagem mais simples e acessível, mantendo a precisão do conteúdo.

  3. Definições contextuais: Sempre que apropriado, incluir uma breve explicação do termo na primeira ocorrência no texto, evitando dependência exclusiva do glossário.

  4. Consistência terminológica: Garantir que os mesmos termos são utilizados de forma consistente em todo o website, evitando variações que possam gerar confusão.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #30 Informações primárias não possuem tamanho mínimo recomendado

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

  O tipo de letra do corpo do documento é adequado e o tamanho da letra é, no mínimo, de 12 pontos.
  – ver requisito 2.1 na lista Conteúdo

  Notas Gerais

  • Para garantir a legibilidade do corpo de texto, este deve ter um tamanho igual ou superior a 12pt, que equivale a 16px.

  O website possui informações primárias com tamanho inferior a 12pontos(16px) por exemplo na página Contactos Gerais, os textos informativos sobre “Farmácias de Serviço” estão abaixo do valor mínimo recomendado. (Figura 1)

  

  Figura 1 - Verificação do tamanho do texto com apenas 12px

  Há blocos de textos de páginas interiores com tamanho inferior ao recomendado. Por exemplo, na página Balcão Único do Prédio (BUPi) (Figura 2)

  

  Figura 2 - Bloco de texto sobre o Balcão Único do Prédio (BUPi) com tamanho de 13px

  Há botões de ação principal, com tamanho inferior ao recomendado. Por exemplo na secção “Outras Notícias” da página inicial com o botão “Ver mais notícias” com tamanho de apenas 15px. (Figura 3)

  

  Figura 3 - Verificação do tamanho de texto em botões no website

  Além disso, ainda "Página inicial" há componentes com informações primárias por exemplo textos informativos da modal "Privacidade", com tamanho de 15px. E os botões dos cookies com dimensão de apenas 13px. (Figura 4)

  

  Figura 4 - Verificação do tamanho de texto para aceitação dos cookies

  Existem formulários no website cujas labels associadas aos campos de preenchimento obrigatório, nomeadamente caixas de texto e radio buttons, apesar de constituírem informação primária, apresentam um tamanho inferior ao recomendado. Por exemplo, no formulário Bolsa de emprego as labels “Endereço”, “Localidade” e “Código Postal” com tamanho de 14.6px. (Figura 5)

  

  Figura 5- Textos com informações primárias do formulário da “Bolsa de emprego” com dimensão inferior ao recomendado

  Outros exemplos de formulários com informações primárias, com texto inferior ao recomendado:

  • https://www.mun-celoricodebasto.pt/visite-celorico/onde-ficar/#adicionar-estabelecimento
  • https://www.mun-celoricodebasto.pt/sustentabilidade/destino-turistico-sustentavel/
  • https://www.mun-celoricodebasto.pt/viver/ambiente-e-recursos-naturais/papersu-2030/
  • https://www.mun-celoricodebasto.pt/viver/planeamento-territorial-e-gestao-urbanistica/planos-e-programas-de-ordenamento-do-territorio/pdm-plano-diretor-municipal/participe-no-futuro-pdm/

  O conteúdo do site fica desformatado em resoluções mais pequenas

  Todos os conteúdos do site devem ser responsivos para garantir a sua legibilidade na maioria das resoluções e quando são escalados para tamanhos superiores.

  Verificámos que, ao alterar a resolução para uma mais pequena por exemplo iPad Mini o texto do menu principal ficou desformatado e com tamanho de 11px. (Figura 6)

  

  Figura 6- Textos do menu com tamanho inferior ao recomendado em resoluções mais pequenas

  Recomendação de melhoria
  É necessário rever todo website para ser corrigido os textos de informações primárias, para um tamanho igual ou superior ao recomendado. As páginas deverão ser revistas para garantir que todo o conteúdo se adapta a diferentes resoluções de ecrã.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #33 Existem blocos de textos 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

  Notas Gerais

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

  Verificamos que na página inicial há blocos de textos, por exemplo na secção Fundos Comunitários que apresentam largura superior ao recomendado por linha. (Figura 1)

  

  Figura 1 - Análise de bloco de texto com ferramenta WordCounter com 127 caracteres

  Outras evidências (NOK)

  • https://www.mun-celoricodebasto.pt/#painel-2089-info
  • https://www.mun-celoricodebasto.pt/#painel-2119-info
  • https://www.mun-celoricodebasto.pt/#painel-2122-info
  • https://www.mun-celoricodebasto.pt/#painel-2110-info
  • https://www.mun-celoricodebasto.pt/#painel-2106-info

  Recomendação
  Revisar blocos de textos para garantir que não é ultrapassado o número máximo de caracteres por linha. Recomendamos 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).

  Evidências na largura do bloco de texto (OK)


  • https://www.mun-celoricodebasto.pt/servicos/financas-municipais-e-patrimonio/
  • https://www.mun-celoricodebasto.pt/servicos/policia-municipal-de-celorico-de-basto/
  • https://www.mun-celoricodebasto.pt/servicos/consulta-publica/

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #35 O espaçamento entre linhas está abaixo do recomendado

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

  O espaçamento entre linhas não é inferior a 1.5x o tamanho da letra.
  – ver requisito 2.4 na lista Conteúdo

  Notas gerais

  • Para assegurar uma boa leitura, o espaçamento entre linhas não deve ser inferior a 1.5x em relação ao tamanho do texto a ser analisado.

  Evidência 01
  Há blocos de textos nas página Inicial, por exemplo na secção Atalhos, em que o espaçamento entre linhas é de 22.4px para um tamanho de letra de 16px. (Figura 1)



  

  Figura 1 - Textos com espaçamento inferior ao recomendado

  Evidência 02
  O formulário Inquérito aos TURISTAS possui blocos de textos com espaçamento apenas 23.4px para um tamanho de letra de 18px. (Figura 2)

  

  Figura 2 - Textos das perguntas do Inquérito com espaçamento inferior ao recomendado

  Recomendação

  Relativamente à evidência 01, o espaçamento deveria ser, no mínimo, de 24 px. Já na evidência 02, o espaçamento mínimo recomendado é de 27 px. É necessário rever todo o website, incluindo a informação presente nos formulários, de forma a garantir o cumprimento do espaçamento mínimo recomendado em função do tamanho da letra.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #48 Excesso de opções no menu de navegação

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.1

  Nenhum nível de navegação tem mais de 9 opções.
  – ver requisito 3.1 na lista Conteúdo

  Evidências:

  O menu de rodapé apresenta 13 opções, o que compromete a sua clareza e organização enquanto elemento de navegação principal. Este deve ser simplificado e estruturado em secções lógicas, de forma a reduzir a carga cognitiva e facilitar a navegação, idealmente não excedendo 9 opções por grupo.

  

  Figura 1: Imagem do menu do rodapé com 13 opções.

  Nota:

  O menu secundário não deve exceder o limite de 9 opções, uma vez que funciona como extensão direta do menu principal e desempenha um papel fundamental na navegação do utilizador. A existência de um número excessivo de opções pode comprometer a clareza e a usabilidade da interface.

  Atualmente, verifica-se que este limite é ultrapassado na secção de serviços (Ver figura 2).

  

  Figura 2: Imagem do menu de serviços com 12 opções.

  Recomendações:

  Recomenda-se a reorganização destes menus, de forma a reduzir o número de itens apresentados e a estruturar a informação de modo mais claro, simples e intuitivo, promovendo uma melhor experiência de utilização e conformidade com os princípios de acessibilidade.

  • Com vista à melhoria da usabilidade e conformidade com os princípios de acessibilidade, recomenda-se:

  • Reduzir o número de opções no subnível, agrupando conteúdos relacionados sob categorias mais abrangentes.

  • Reorganizar a arquitetura de informação para garantir uma hierarquia mais simples e intuitiva.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #84 Discrepâncias entre o menu principal e menu secundário

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.2

  Evidências:

  Relativamente à relação entre o menu secundário e o menu principal, foram identificadas algumas discrepâncias que podem gerar confusão. Seguem os casos observados:

  Opções do menu principal presentes dentro de outras opções no menu secundário.

  Verificou-se que a opção do menu principal "Investir" surge também no menu secundário, respetivamente dentro da opção "Viver".

  

  Figura 1: Imagem da página investir com os breadcrumbs da opção "Viver"

  Opções do menu principal com páginas diferentes ou ausência de menu secundário:

  As seguintes páginas do menu principal apresentam os seus subníveis organizados em blocos, mas não incluem um menu secundário:

  • https://www.mun-celoricodebasto.pt/municipio/
  • https://www.mun-celoricodebasto.pt/viver/

  Por outro lado, as seguintes páginas — também presentes no menu principal — incluem um menu secundário com opções adicionais:

  • https://www.mun-celoricodebasto.pt/viver/investir/
  • https://www.mun-celoricodebasto.pt/servicos/
  • https://www.mun-celoricodebasto.pt/sustentabilidade/
  • https://www.mun-celoricodebasto.pt/visite-celorico/

  Estas inconsistências na estrutura de navegação prejudicam a fluidez da experiência do utilizador e podem causar confusão ao navegar no website.

  Existem opções no menu secundário que não estão presentes no menu principal:

  Na figura 2 é possível observar que a organização dos dois menus é bastante diferente. Por exemplo, "Glossário" aparece no menu secundário, enquanto no menu principal não está presente.

  

  Figura 2: Imagem com a falta da opção "Glossário" no menu principal

  A opção “Desenvolvimento Económico e Empreendedorismo” apresenta uma estrutura inconsistente entre menus. No menu principal, surge como uma das várias opções ao mesmo nível dentro de “Investir”, enquanto no menu secundário é apresentada como um item de segundo nível que agrega as restantes opções de “Investir” como subníveis.

  

  Figura 3: Imagem das diferenças de opções do menu "Investir" no menu principal e secundário.

  Recomendações:

  Adicionalmente, recomenda-se a revisão do menu secundário, assegurando o seu alinhamento com o menu principal e com a estrutura global das páginas. É fundamental garantir consistência na organização e na nomenclatura dos menus ao longo de todo o website, promovendo uma navegação mais clara, intuitiva e acessível para todos os utilizadores, especialmente em contextos com múltiplos níveis e percursos de navegação.

• evidência: issue #54 Falta de Indicação de Navegação em páginas

  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:

  Embora o menu principal esteja disponível em todas as páginas, é necessário incluir um mecanismo adicional de orientação, como breadcrumbs ou outra indicação de localização. Este elemento deve permitir ao utilizador compreender, de forma clara e consistente, a sua posição dentro da estrutura do website em todas as páginas.

  Apesar de existir breadcrumbs pelo website, é possível visualizar que nos seguintes websites os breadcrumbs não estão presentes:

  • https://www.mun-celoricodebasto.pt/eventos/liga-255-718-348/
  • https://www.mun-celoricodebasto.pt/eventos/feira-da-saude-2/
  • https://www.mun-celoricodebasto.pt/eventos/heart-run/
  • https://www.mun-celoricodebasto.pt/eventos/caminhada-rota-do-mel/
  • https://www.mun-celoricodebasto.pt/2026/04/24/
  • https://www.mun-celoricodebasto.pt/2026/04/27/
  • https://www.mun-celoricodebasto.pt/2026/04/23/

  

  Figura 1: Imagem das páginas interiores da Agenda e Notícias sem breadcrumbs.

  Notas de melhoria:

  Relativamente à relação entre o menu secundário e o menu principal, foram identificadas algumas discrepâncias que podem gerar confusão. Seguem os casos observados:

  Opções do menu principal presentes dentro de outras opções no menu secundário.

  Verificou-se que a opção do menu principal "Investir" surge também no menu secundário, respetivamente dentro da opção "Viver".

  

  Figura 2: Imagem da página investir com os breadcrumbs da opção "Viver"

  Opções do menu principal com páginas diferentes ou ausência de menu secundário:

  As seguintes páginas do menu principal apresentam os seus subníveis organizados em blocos, mas não incluem um menu secundário:

  • https://www.mun-celoricodebasto.pt/municipio/
  • https://www.mun-celoricodebasto.pt/viver/

  Por outro lado, as seguintes páginas — também presentes no menu principal — incluem um menu secundário com opções adicionais:

  • https://www.mun-celoricodebasto.pt/viver/investir/
  • https://www.mun-celoricodebasto.pt/servicos/
  • https://www.mun-celoricodebasto.pt/sustentabilidade/
  • https://www.mun-celoricodebasto.pt/visite-celorico/

  Estas inconsistências na estrutura de navegação prejudicam a fluidez da experiência do utilizador e podem causar confusão ao navegar no website.

  Existem opções no menu secundário que não estão presentes no menu principal:

  Na figura 3 é possível observar que a organização dos dois menus é bastante diferente. Por exemplo, "Glossário" aparece no menu secundário, enquanto no menu principal não está presente.

  

  Figura 3: Imagem com a falta da opção "Glossário" no menu principal

  A opção “Desenvolvimento Económico e Empreendedorismo” apresenta uma estrutura inconsistente entre menus. No menu principal, surge como uma das várias opções ao mesmo nível dentro de “Investir”, enquanto no menu secundário é apresentada como um item de segundo nível que agrega as restantes opções de “Investir” como subníveis.

  

  Figura 4: Imagem das diferenças de opções do menu "Investir" no menu principal e secundário.

  Recomendações:

  Recomenda-se a inclusão de breadcrumbs em todas as páginas, de forma a fornecer uma referência clara da localização do utilizador dentro do website.

  Adicionalmente, recomenda-se a revisão do menu secundário, assegurando o seu alinhamento com o menu principal e com a estrutura global das páginas. É fundamental garantir consistência na organização e na nomenclatura dos menus ao longo de todo o website, promovendo uma navegação mais clara, intuitiva e acessível para todos os utilizadores, especialmente em contextos com múltiplos níveis e percursos de navegação.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #56 Hiperligações não identificáveis como clicáveis no website

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

  As hiperligações de texto não devem ser diferenciadas apenas com base na cor.
  – ver requisito 3.3 na lista Conteúdo

  Evidências:

  Atualmente, verificam-se situações em que os links não se distinguem adequadamente do texto corrente, sendo identificáveis apenas através da cor, por interação (hover) ou, em alguns casos, sem qualquer elemento diferenciador (ver Figura 1). Esta abordagem não cumpre as boas práticas de acessibilidade, uma vez que dificulta a identificação de elementos interativos por parte dos utilizadores.

  Apresentam-se de seguida alguns exemplos identificados:

  

  Figura 1: Imagem dos direitos no rodapé com hiperligação sem qualquer diferenciação

  

  Figura 2: Imagem de hiperligação para a página de notícias, sem indicação visual. Disponível em: https://www.mun-celoricodebasto.pt/ha-festa-na-praca-assinala-identidade-e-dinamizacao-cultural-em-gandarela-de-basto/

  

  Figura 3: Imagem com o link “política de privacidade” sem sublinhado ou diferenciação extra.

  Na página inicial, os blocos de conteúdo (“Desporto e Lazer”, “Informações Úteis”, “Cultura e Tradições”, “Visite Celorico” e “História”) apresentam o texto “SABER MAIS” sem qualquer aparência de elemento interativo, sendo apresentado como texto simples, sem estilo de botão, contraste reforçado ou indicação visual de clicabilidade.

  Adicionalmente, foi identificado que tanto o texto “SABER MAIS” como as imagens associadas são clicáveis e direcionam para o mesmo destino, contudo nenhuma das áreas apresenta feedback visual de interação (como hover, foco ou destaque), o que dificulta a perceção de que ambos os elementos são interativos.

  

  Figura 04: Os blocos de conteúdo na página inicial apresentam o texto “Saber mais” sem aparência de elemento interativo

  Outros exemplos:

  • https://www.mun-celoricodebasto.pt/municipio/mensagem-do-presidente/

  • https://www.mun-celoricodebasto.pt/municipio/assembleia-municipal/

  • https://www.mun-celoricodebasto.pt/municipio/assembleia-municipal/competencias/

  • https://www.mun-celoricodebasto.pt/municipio/breve-historia-do-concelho/

  • https://www.mun-celoricodebasto.pt/visite-celorico/

  • https://www.mun-celoricodebasto.pt/visite-celorico/comer-e-beber/
  • https://www.mun-celoricodebasto.pt/eventos/xxi-festa-internacional-das-camelias/
  • Documentos para descarregar https://www.mun-celoricodebasto.pt/sustentabilidade/codigos-de-etica/
  • Secção “Notícias relacionadas” https://www.mun-celoricodebasto.pt/viver/cultura-e-associativismo/

  Recomendações:

  Garantir que todos os links:

  • Sejam visualmente distinguíveis do texto normal sem depender exclusivamente da cor;

  • Incluam sublinhado ou outro indicador visual consistente;

  • Mantenham consistência em todos os estados (normal, hover, focus).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #21 Ausência de índice com hiperligações internas em páginas com conteúdo extenso

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: 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

  Ponto 01
  Página: https://www.mun-celoricodebasto.pt/viver/educacao-e-formacao/conselho-municipal-de-educacao/

  Na página “Conselho Municipal de Educação”, apesar de se tratar de um conteúdo extenso com múltiplas secções e elevada altura de scroll, não existe um índice de conteúdos no topo com hiperligações internas para as diferentes secções e subsecções.

  A ausência deste elemento dificulta a navegação rápida dentro da página, obrigando o utilizador a percorrer manualmente todo o conteúdo para localizar a informação pretendida.

  

  Figura 01 – Página extensa sem índice de conteúdos no topo com hiperligações internas, dificultando a navegação entre secções.

  Outros exemplos
  https://www.mun-celoricodebasto.pt/viver/habitacao-e-reabilitacao-urbana/reabilitacao-urbana-arus/
  https://www.mun-celoricodebasto.pt/viver/ambiente-e-recursos-naturais/papersu-2030/
  https://www.mun-celoricodebasto.pt/viver/investir/links-de-apoio/
  https://www.mun-celoricodebasto.pt/servicos/servicos-ao-cidadao/balcao-unico-do-predio-bupi/
  https://www.mun-celoricodebasto.pt/servicos/consulta-publica/
  https://www.mun-celoricodebasto.pt/sustentabilidade/story-top100/

  Recomendação
  Recomenda-se a implementação de um índice de conteúdos no topo da página, com hiperligações internas para as principais secções e subsecções.

  Este índice deve refletir a hierarquia dos cabeçalhos existentes, permitindo uma navegação mais rápida, estruturada e acessível em páginas com grande volume de informação.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #9 Conteúdo textual com quebra de legibilidade em diferentes resoluções de ecrã

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 4.2

  O layout do sítio Web é adaptável a plataformas móveis sem necessidade de efetuar varrimento horizontal.
  – ver requisito 4.2 na lista Conteúdo

  Ponto 01
  Página: https://www.mun-celoricodebasto.pt/municipio/freguesias-do-concelho/

  Na página das freguesias, os nomes apresentados no mapa não se adaptam corretamente a diferentes tamanhos de ecrã, sendo parcialmente cortados tanto em resoluções de desktop como em dispositivos móveis.

  Este comportamento compromete a legibilidade completa da informação e indica uma limitação na responsividade do componente, afetando a correta apresentação do conteúdo em diferentes contextos de visualização.

  

  Figura 01 – O mapa de freguesias apresenta nomes parcialmente cortados em versão desktop, comprometendo a legibilidade completa da informação

  

  Figura 02 – O mapa de freguesias apresenta nomes parcialmente cortados em dispositivos móveis, comprometendo a legibilidade da informação

  Recomendação
  Garantir que o mapa de freguesias seja totalmente responsivo, assegurando que os nomes sejam apresentados de forma completa e legível em qualquer resolução de ecrã.

  Deve ser ajustado o comportamento do componente para evitar cortes de texto, garantindo uma adaptação adequada tanto em desktop como em dispositivos móveis.

  Ponto 02
  Página: https://www.mun-celoricodebasto.pt/viver/investir/

  Na página, o acesso à funcionalidade “Entrar em contacto”, presente no card do titular do(s) pelouro(s), deixa de estar disponível em dispositivos móveis quando o menu de navegação é convertido para o formato de ícone (“menu hambúrguer”).

  Adicionalmente, em alguns dispositivos móveis (ex.: iPad Pro), o formulário de contacto não se adapta corretamente à largura do ecrã, ficando parcialmente cortado e comprometendo a sua utilização.

  

  Figura 01 – Funcionalidade “Entrar em contacto” não disponível na versão móvel, deixando de estar acessível ao utilizador.

  

  Figura 01 – Formulário de contacto com problemas de adaptação em dispositivos móveis, ficando parcialmente cortado em ecrãs como iPad Pro.

  Recomendação
  Garantir que todo o layout do website, possui comportamento responsive e adapta-se às diferentes resoluções de ecrã, sem necessidade de fazer varrimento horizontal.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #47 Gráfico interativo dependente de hover com limitações de acessibilidade

  etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: R 5.1

  Não existem elementos interativos acionados apenas com a passagem do rato.
  – ver requisito 5.1 na lista Conteúdo

  Sugestão de melhoria:
  Página: Página: https://www.mun-celoricodebasto.pt/municipio/assembleia-municipal/constituicao/

  O gráfico interativo da página “Assembleia Municipal – Constituição”, gerado por ferramenta externa. Apesar de visualmente informativo, apresenta limitações de acessibilidade e de clareza funcional que podem comprometer a compreensão da informação por diferentes perfis de utilizadores.

  Atualmente, a interação com os elementos circulares do gráfico baseia‑se essencialmente em efeitos visuais de hover (alteração de opacidade e destaque por grupos).

  Esta abordagem apresenta vários constrangimentos:

  • Utilizadores de teclado ou de dispositivos táteis não beneficiam do efeito hover.
  • Utilizadores de leitores de ecrã não recebem qualquer indicação de que existe uma relação funcional entre os elementos do gráfico e a tabela de partidos.
  • O clique nos elementos não produz uma mudança de estado clara, nem desencadeia uma ação funcional adicional, o que pode criar uma falsa expectativa de interatividade mais aprofundada.
  • A correspondência entre cores e partidos é exclusivamente visual, o que dificulta ou impede o acesso à informação por pessoas com deficiência visual ou daltonismo.

   

  

  Figura 01 – Elementos do gráfico com interação limitada ao hover, sem ação ou feedback ao clique, podendo gerar expectativa de interatividade não suportada

  Recomendações de melhoria

  Clarificar ou reduzir a interatividade: Se o gráfico não permite ações adicionais além do destaque visual, deve ser claramente apresentado como um gráfico estático, evitando indícios de clique (ex.: cursor em forma de link).

  Alternativamente, se a interatividade for mantida, o clique deve produzir um efeito inequívoco (por exemplo, seleção persistente, filtragem da tabela ou apresentação de informação complementar).

  Garantir acessibilidade por teclado e leitores de ecrã: As opções de destaque/filtragem devem poder ser ativadas via teclado. Cada grupo ou partido representado no gráfico deve ter uma descrição textual acessível.

  Não depender exclusivamente da cor para transmitir informação
 Deve ser reforçada a diferenciação entre partidos através de texto, símbolos ou padrões, garantindo conformidade com o princípio de que a cor não pode ser o único meio de comunicação da informação.

  Adicionar uma explicação contextual como uma nota explicativa antes do gráfico, indicando claramente o que o gráfico representa, e garantir que a informação essencial está igualmente disponível na tabela.

• evidência: issue #8 Conteúdos que dependem de hover para serem visíveis ou legíveis

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.1

  Não existem elementos interativos acionados apenas com a passagem do rato.
  – ver requisito 5.1 na lista Conteúdo

  Ponto 01
  Página: https://www.mun-celoricodebasto.pt/3o-passeio-extreme-dos-azelhas-voltou-a-atrair-apaixonados-pelo-desporto-motorizado/

  Os elementos de navegação do breadcrumb apresentam problemas de visibilidade, uma vez que o texto só se torna legível ou claramente visível quando o utilizador interage com o elemento em estado de hover.

  Este comportamento compromete a perceção da estrutura de navegação da página, especialmente para utilizadores que não utilizam mouse (ex: navegação por teclado ou dispositivos táteis), dificultando a compreensão do contexto da localização dentro do site.

  

  Figura 01 – Breadcrumb com elementos cujo texto só é visível em estado de hover, comprometendo a leitura e a perceção da navegação estrutural

  Outros exemplos
  https://www.mun-celoricodebasto.pt/celorico-de-basto-avanca-para-a-3-a-edicao-do-orcamento-participativo-jovem/
  https://www.mun-celoricodebasto.pt/viver/educacao-e-formacao/ensino-superior/
  https://www.mun-celoricodebasto.pt/viver/planeamento-territorial-e-gestao-urbanistica/geoportal/
  https://www.mun-celoricodebasto.pt/viver/planeamento-territorial-e-gestao-urbanistica/planos-e-programas-de-ordenamento-do-territorio/instrumentos-de-gestao-territorial-supramunicipais/
  https://www.mun-celoricodebasto.pt/viver/planeamento-territorial-e-gestao-urbanistica/gabinete-tecnico-florestal/caca-e-pesca/concessao-de-pesca-desportiva/

  Recomendação
  Garantir que os elementos do breadcrumb sejam sempre visíveis no estado normal, independentemente da interação do utilizador.

  Deve ser evitada a dependência de estados de hover para a leitura de informação de navegação, assegurando legibilidade contínua e acessibilidade para navegação por teclado e dispositivos táteis.

  Ponto 02
  Página: https://www.mun-celoricodebasto.pt/municipio/freguesias-do-concelho/

  No mapa de freguesias do concelho, os nomes das freguesias apenas são totalmente visíveis ou legíveis quando o utilizador interage com o elemento em estado de hover.

  Em dispositivos móveis, a interação equivalente ocorre apenas mediante clique/toque no elemento.

  Este comportamento compromete a acessibilidade e a compreensão da informação, uma vez que impede a leitura completa sem interação, dificultando o acesso ao conteúdo por utilizadores que navegam por teclado, dispositivos táteis ou tecnologias assistivas.

  

  Figura 02 – Nomes das freguesias no mapa apenas visíveis em estado de hover, dificultando a leitura contínua da informação.

  Recomendação

  Garantir que os nomes das freguesias estejam sempre visíveis de forma permanente, independentemente da interação do utilizador.

  Deve ser evitada a dependência de estados de hover para apresentação de informação textual essencial, assegurando acessibilidade e leitura contínua em todos os contextos de utilização.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #7 Elementos interativos com dimensão inferior ao mínimo recomendado (44px)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.2

  Os elementos interativos têm uma dimensão mínima de 44px CSS (44 pontos), vertical e horizontal.
  – ver requisito 5.2 na lista Conteúdo

  Ponto 01
  Página: https://www.mun-celoricodebasto.pt/

  As setas de navegação do carrossel da agenda apresentam uma dimensão inferior ao recomendado (30px), assim como o botão de partilha, com 36px.

  Estas dimensões podem dificultar a sua utilização, especialmente em dispositivos táteis.

  

  Figura 01 – Setas de navegação do carrossel da agenda com dimensão inferior ao mínimo recomendado (44px), dificultando a sua utilização

  

  Figura 02 – Elemento de partilha com dimensão inferior ao mínimo recomendado, comprometendo a acessibilidade e a facilidade de interação, especialmente em dispositivos táteis

  Outros exemplos
  https://www.mun-celoricodebasto.pt/3o-passeio-extreme-dos-azelhas-voltou-a-atrair-apaixonados-pelo-desporto-motorizado/
  https://www.mun-celoricodebasto.pt/celorico-de-basto-avanca-para-a-3-a-edicao-do-orcamento-participativo-jovem/

  Recomendação
  Aumentar a área clicável das setas de navegação para, no mínimo, 44px por 44px, garantindo uma interação mais fácil e precisa em diferentes dispositivos.

  Ponto 02
  Página: https://www.mun-celoricodebasto.pt/viver/investir/apoio-ao-empresario-investidor/

  No formulário da secção “Bolsa de Emprego”, os elementos interativos do tipo checkbox e radio buttons apresentam uma dimensão inferior ao recomendado (13px).

  Esta dimensão reduzida pode dificultar a sua seleção, especialmente em dispositivos táteis ou para utilizadores com dificuldades motoras, comprometendo a acessibilidade e a usabilidade da interface.

  

  Figura 01 – Formulário da “Bolsa de Emprego” com checkboxes e radio buttons de dimensão reduzida (13px), o que pode dificultar a interação em dispositivos táteis e não cumpre a dimensão mínima recomendada de 44px CSS.

  Outros exemplos
  https://www.mun-celoricodebasto.pt/municipio/camara-municipal/executivo-municipal/
  https://www.mun-celoricodebasto.pt/visite-celorico/onde-ficar/#cat-109-info
  https://www.mun-celoricodebasto.pt/viver/ambiente-e-recursos-naturais/papersu-2030/
  https://www.mun-celoricodebasto.pt/sustentabilidade/destino-turistico-sustentavel/
  https://www.mun-celoricodebasto.pt/festa-internacional-das-camelias/

  Recomendação
  Recomenda-se aumentar a área clicável dos checkboxes e radio buttons para, no mínimo, 44px de altura e largura, conforme boas práticas de acessibilidade.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #40 Há botões principais que não têm destaque suficiente

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.3

  Há apenas um botão de ação principal por página e o mesmo encontra-se destacado.
  – ver requisito 5.3 na lista Conteúdo

  Ponto 01
  Página: https://www.mun-celoricodebasto.pt/festa-internacional-das-camelias/

  No pop-up do mapa interativo da página da Festa Internacional das Camélias, ao selecionar um marcador, são apresentados dois botões de ação: “Direções” (ação secundária) e “Ampliar” (ação principal).

  Ambos os botões não apresentam diferenciação visual clara entre si, mantendo estilos muito semelhantes.
  Esta falta de hierarquia visual dificulta a perceção imediata de qual é a ação principal e qual é a ação secundária, podendo gerar ambiguidade na interação do utilizador.

  

  Figura 01 – Pop-up do mapa interativo com ausência de diferenciação visual entre ação primária e secundária nos botões “Direções” e “Ampliar”, comprometendo a hierarquia de ações

  Recomendação
  Diferenciar visualmente as ações do pop-up, destacando o botão “Ampliar” como primário (mais evidência) e reduzindo o destaque do “Direções” como secundário, garantindo hierarquia clara e consistente no design.

  Ponto 02
  Página: https://www.mun-celoricodebasto.pt/campo-da-feira-de-gandarela-de-basto-em-celorico-de-basto-requalificado/

  Na página do Campo da Feira de Gandarela de Basto, os botões de navegação “Anterior” e “Seguinte” apresentam falta de hierarquia visual clara entre ações primárias e secundárias.

  Os botões secundários competem visualmente com os elementos de ação principal, não existindo destaque suficiente para a ação mais relevante.

  Isto reduz a perceção imediata da prioridade das ações disponíveis e pode causar ambiguidade na interação do utilizador.

  Outros exemplos de inconsistência
  O mesmo padrão de inconsistência visual é identificado em outras páginas do website, onde botões de navegação com a ação “Anterior” e “Seguinte” apresentam estilos diferentes entre si, comprometendo a consistência da interface.

  Páginas:
  https://www.mun-celoricodebasto.pt/servicos/consulta-publica/
  https://www.mun-celoricodebasto.pt/servicos/taxas-e-licencas/#355-355-wpfd-taxas-e-precos-municipais-p2

  

  Figura 02 – Botões de navegação “Anterior” e “Seguinte” com ausência de hierarquia visual clara entre ações principais e secundárias, comprometendo a distinção de prioridade das ações

  

  Figura 03 – Inconsistência visual nos botões de navegação “Anterior” e “Seguinte” em diferentes páginas do website, comprometendo a consistência da interface

  Recomendação
  Garantir consistência visual dos componentes de navegação em todo o website, assegurando que botões com a mesma função (“Anterior” e “Seguinte”) seguem o mesmo padrão de hierarquia visual e estilo, de forma alinhada com o sistema de design.

  Ponto 03
  Página: https://www.mun-celoricodebasto.pt/servicos/documentos/#51-374-wpfd-avisos-e-despachos

  Em algumas subpáginas do website, o botão “Voltar” (ação principal de navegação) é apresentado com estilo semelhante a texto simples, sem destaque visual suficiente que o diferencie de conteúdos não interativos ou ações secundárias.

  Esta ausência de hierarquia visual clara dificulta a perceção de que se trata da principal ação de navegação da página, podendo comprometer a orientação do utilizador dentro da estrutura do website.

  

  Figura 04 – Botão “Voltar” sem destaque visual como ação principal de navegação, dificultando a perceção da sua importância dentro da página

  Outros exemplos
  https://www.mun-celoricodebasto.pt/servicos/fundos-comunitarios/#375-376-wpfd-projetos-cofinanciados
  https://www.mun-celoricodebasto.pt/servicos/consulta-publica/#373-526-wpfd-hasta-publica-tapada-da-pinha

  Recomendação

  Garantir que o botão “Voltar”, enquanto ação principal de navegação nestas páginas, apresente destaque visual consistente com a sua importância, assegurando hierarquia clara em relação a texto e outros elementos secundários, de acordo com o sistema de design do website.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #29 Elementos interativos com baixo contraste dificultam a perceção de clicabilidade

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

  Elementos gráficos interativos têm de aparentar ser clicáveis.
  – ver requisito 5.4 na lista Conteúdo

  Ponto 01
  Página: https://www.mun-celoricodebasto.pt/viver/desenvolvimento-social-e-saude/saude/

  Na página, o botão “Ler mais / Ler menos” apresenta-se sem preenchimento visível e com uma linha de contorno muito fina e de baixo contraste. Esta apresentação dificulta a perceção do elemento como botão clicável, podendo passar despercebido ou ser interpretado como texto comum.

  Este problema é igualmente observado em modo dark, onde o contraste permanece insuficiente, agravando ainda mais a legibilidade devido ao fundo escuro da interface.

  

  Figura 01 – Botão “Ler mais / Ler menos” com baixo contraste e sem preenchimento visível, não aparentando claramente ser um elemento clicável.

  Outro exemplo
  https://www.mun-celoricodebasto.pt/viver/planeamento-territorial-e-gestao-urbanistica/gabinete-tecnico-florestal/vespa-velutina/

  Recomendação
  Recomenda-se reforçar a distinção visual do botão “Ler mais / Ler menos”, garantindo contraste suficiente em relação ao fundo e uma aparência clara de elemento interativo.

  Para tal, deve ser considerado o uso de preenchimento de cor, aumento da espessura do contorno e aplicação de estados visuais (hover, foco e ativo), de forma a melhorar a perceção de clicabilidade e acessibilidade.

  Ponto 02
  Página: https://www.mun-celoricodebasto.pt/viver/desenvolvimento-social-e-saude/cpcj/

  Na página e noutras áreas do website, elementos interativos apresentados em formato de “card” (ex.: “Comissários CPCJ” e “A CPCJ Intervém quando”).

  O contraste entre as cores apresenta um rácio aproximado de 1.2:1, o que dificulta a distinção visual dos elementos enquanto áreas clicáveis ou interativas.

  Este problema é igualmente observado em modo dark, onde o contraste permanece insuficiente, agravando ainda mais a legibilidade devido ao fundo escuro da interface.

  Esta baixa diferenciação pode comprometer a perceção de interatividade, fazendo com que os elementos passem despercebidos ou sejam interpretados como conteúdo estático.

  

  Figura 02 – Elementos em formato de card com contraste aproximado de 1.2:1 em relação ao fundo, dificultando a distinção visual enquanto áreas interativas

  

  Figura 03 – Menu principal com baixo contraste entre os itens de navegação e o fundo, dificultando a perceção dos elementos interativos.

  Outros exemplos
  https://www.mun-celoricodebasto.pt/viver/educacao-e-formacao/acao-social-escolar/
  https://www.mun-celoricodebasto.pt/viver/educacao-e-formacao/conselho-municipal-de-educacao/#868-868-wpfd-top

  Recomendação
  Recomenda-se aumentar o contraste dos elementos interativos (cards e menu principal), garantindo uma distinção visual clara em relação ao fundo da página.

  Devem ser utilizados elementos de destaque como cores mais contrastantes, bordas ou sombras, bem como estados de interação consistentes, de forma a reforçar a perceção de clicabilidade e melhorar a usabilidade.

  Ponto 03
  Página: https://www.mun-celoricodebasto.pt/servicos/protecao-civil/

  Na página “Proteção Civil”, o breadcrumb apresenta problemas de contraste no elemento interativo correspondente às hiperligações.

  O sublinhado aplicado aos links do breadcrumb possui baixo contraste em relação ao fundo, o que dificulta a distinção entre texto estático e elementos clicáveis.

  Esta fraca diferenciação visual pode comprometer a perceção de interatividade, especialmente para utilizadores com dificuldades visuais ou em condições de luminosidade reduzida.

  

  Figura 04 – Breadcrumb com hiperligações de baixo contraste no sublinhado, dificultando a distinção entre texto estático e elementos clicáveis

  Recomendação
  Recomenda-se aumentar o contraste e a visibilidade dos links no breadcrumb, garantindo uma distinção clara face ao texto não interativo.
  Deve ser assegurado um sublinhado ou estilo de link mais evidente e consistente com os restantes elementos interativos do site, de forma a melhorar a perceção de clicabilidade e a acessibilidade da navegação.

  Ponto 04
  Página: https://www.mun-celoricodebasto.pt/

  Na versão mobile, foram identificados problemas de contraste em elementos interativos da secção “Atalhos”, nomeadamente nos botões de seta e de fechar.

  Estes elementos não apresentam contraste suficiente em relação ao fundo, o que dificulta a sua identificação como componentes interativos e pode comprometer a sua utilização, especialmente em condições de menor visibilidade.

  

  Figura 05 – Botões de atalho na versão mobile com baixo contraste dos ícones de seta e fechar em relação ao fundo.

  Recomendação
  Recomenda-se aumentar o contraste dos botões de seta e de fechar na versão mobile, garantindo uma distinção clara em relação ao fundo.
  Devem ser aplicados valores de contraste adequados e estilos visuais consistentes com os restantes elementos interativos do site, de forma a melhorar a perceção de clicabilidade e a acessibilidade.

  Ponto 05
  Página: https://www.mun-celoricodebasto.pt/municipio/

  A modal de pesquisa nas páginas interiores do website apresenta problemas de contraste no botão “Procurar”.

  O elemento não possui contraste suficiente entre o texto e o fundo, apresentando um rácio de 1.09:1, o que dificulta a sua leitura e identificação como elemento interativo.

  Este problema é igualmente observado em modo dark, onde o contraste permanece insuficiente, agravando ainda mais a legibilidade devido ao fundo escuro da interface.

  Este comportamento pode comprometer a usabilidade, especialmente para utilizadores com baixa visão ou em ambientes com pouca luminosidade.

  

  Figura 06 – Botão “Procurar” na modal de pesquisa com baixo contraste entre texto e fundo.

  Recomendação
  Recomenda-se aumentar o contraste do botão “Procurar”, garantindo um rácio mínimo conforme os requisitos de acessibilidade (WCAG).

  Deve ser assegurada uma melhor distinção entre o texto e o fundo do botão, podendo ser necessário ajustar as cores utilizadas ou reforçar o estilo visual do elemento para melhorar a legibilidade e a perceção de interatividade.

  Ponto 06
  Página: https://www.mun-celoricodebasto.pt/municipio/mensagem-do-presidente/

  No modo dark, o botão flutuante de ajuda “Olá, posso ajudar?” associado ao ícone da flor apresenta problemas de visibilidade devido ao baixo contraste entre o elemento e o fundo da interface.

  O contraste medido entre o botão e o fundo em modo dark é de aproximadamente 1.26:1, abaixo do mínimo recomendado de 3:1 para componentes gráficos interativos, comprometendo a sua visibilidade.

  Quando posicionado sobre áreas escuras do website, o botão perde definição visual, ficando parcialmente camuflado e dificultando a sua identificação como elemento interativo disponível para suporte.

  

  Figura 07 – Botão flutuante de ajuda “Olá, posso ajudar?” com ícone de flor em modo dark com baixo contraste com o fundo.

  Recomendação
  Garantir que o botão flutuante de ajuda mantém contraste adequado em todos os modos de visualização, incluindo dark mode, assegurando separação visual consistente em relação ao fundo através de ajustes de cor, sombra, contorno ou camada de destaque, de forma a preservar a sua legibilidade e perceção como elemento interativo.

  Ponto 07
  Página: https://www.mun-celoricodebasto.pt/municipio/mensagem-do-presidente/

  Os ícones de redes sociais apresentados na lateral direita da página apresentam problemas de contraste em relação ao fundo da interface, especialmente em modo dark.

  Os elementos não possuem contraste suficiente para garantir uma perceção clara como componentes interativos, ficando menos visíveis quando sobrepostos a áreas escuras do layout. Este comportamento compromete a sua identificação e reduz a clareza da funcionalidade associada (partilha/acesso a redes sociais).

  O problema impacta a acessibilidade visual, sobretudo para utilizadores com baixa visão ou em condições de luminosidade reduzida.

  

  Figura 08 – Ícones de redes sociais na lateral direita da página com baixo contraste em modo dark.

  Recomendação
  Recomenda-se melhorar o contraste dos ícones de redes sociais no modo dark garantindo maior visibilidade e melhor identificação como elementos interativos podendo ajustar cores adicionar fundo de suporte ou reforçar estados de hover e focus para melhorar a acessibilidade e a usabilidade

  Ponto 08
  Página: https://www.mun-celoricodebasto.pt/municipio/mensagem-do-presidente/

  O botão principal de "Procurar" e o botão “abrir” em dispositivos móveis apresentam baixo contraste no modo dark em relação ao fundo da interface.

  Esta condição reduz a sua visibilidade e dificulta a identificação como elementos interativos, especialmente em contextos de pouca luminosidade ou para utilizadores com baixa visão.

  

  Figura 09 – Botão “Procurar” na pesquisa com baixo contraste em modo dark.

  

  Figura 11 – Botão “Abrir” em dispositivos móveis com baixo contraste em modo dark.

  Recomendação
  Recomenda-se ajustar o contraste destes elementos no modo dark, garantindo uma melhor distinção em relação ao fundo. Pode ser necessário reforçar a cor dos ícones ou do botão, adicionar contornos ou fundos de suporte e garantir estados de hover e focus mais evidentes, de forma a melhorar a acessibilidade e a perceção de interatividade.

• evidência: issue #28 Falsa indicação de interatividade em listas devido ao uso de ícones decorativos

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

  Elementos gráficos interativos têm de aparentar ser clicáveis.
  – ver requisito 5.4 na lista Conteúdo

  Ponto 01
  Página: https://www.mun-celoricodebasto.pt/viver/ambiente-e-recursos-naturais/eco-conselhos/

  Na secção “Eco-conselhos”, nomeadamente nos blocos “Bio-Resíduos”, “Mitos e Monstros”, “Óleo”, “Água” e “Pilhas e baterias”, é apresentada a indicação “Clique nas imagens para ampliar”. No entanto, ao interagir com as imagens, não ocorre qualquer ação.

  Adicionalmente, as imagens não apresentam qualquer feedback visual de interatividade e não são acessíveis via navegação por teclado, sendo ignoradas ao utilizar a tecla Tab.

  Esta situação gera inconsistência entre a instrução apresentada e o comportamento real dos elementos.

  

  Figura 01 – Indicação para clicar nas imagens para ampliar sem que exista funcionalidade associada, sem feedback de interatividade ou suporte à navegação por teclado.

  Recomendação
  Recomenda-se garantir que as imagens associadas à instrução “Clique para ampliar” sejam efetivamente interativas, implementando a funcionalidade de ampliação conforme indicado.

  Caso a funcionalidade não esteja disponível, a instrução deve ser removida para evitar induzir o utilizador em erro.

  Adicionalmente, devem ser assegurados indicadores visuais de interatividade e suporte à navegação por teclado, garantindo uma experiência consistente e acessível.

  Ponto 02
  Página: https://www.mun-celoricodebasto.pt/viver/educacao-e-formacao/projetos-e-programas/

  Na página “Projetos e Programas”, os itens de lista são precedidos por ícones de seta verdes. Estes elementos criam uma forte expectativa de interatividade, sugerindo que os itens são clicáveis ou que conduzem a outra página.

  No entanto, as setas têm apenas função decorativa, não sendo elementos interativos.
  Esta associação visual pode induzir o utilizador em erro quanto à funcionalidade dos elementos.

  

  Figura 01 – Itens de lista com ícones de seta verdes que sugerem interatividade, mas não são clicáveis.

  Outros exemplos
  https://www.mun-celoricodebasto.pt/viver/educacao-e-formacao/acao-social-escolar/
  https://www.mun-celoricodebasto.pt/viver/investir/ecossistema-empresarial/
  https://www.mun-celoricodebasto.pt/viver/investir/links-de-apoio/
  https://www.mun-celoricodebasto.pt/visite-celorico/patrimonio/romanico-de-celorico-de-basto/igreja-do-salvador-de-fervenca/
  https://www.mun-celoricodebasto.pt/viver/habitacao-e-reabilitacao-urbana/reabilitacao-urbana-arus/
  https://www.mun-celoricodebasto.pt/servicos/servicos-ao-cidadao/balcao-unico/

  Recomendação
  Recomenda-se evitar o uso de ícones que sugiram interatividade (como setas) em elementos que não são clicáveis.
  Deve ser utilizada uma marcação visual mais neutra para listas (ex.: bullets simples) ou, caso exista intenção de navegação, transformar os itens em links funcionais.

• evidência: issue #6 Elementos clicáveis sem indicação visual consistente de interação

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

  Elementos gráficos interativos têm de aparentar ser clicáveis.
  – ver requisito 5.4 na lista Conteúdo

  Ponto 01
  Página: https://www.mun-celoricodebasto.pt/

  Os botões “Ver mais” apresentam pouco contraste no estado normal, com um contorno muito discreto que dificulta a sua identificação como elementos interativos.

  O destaque só é percebido ao passar o rato, o que pode não ser suficiente em todos os contextos de utilização.

  

  Figura 01 – Botões “Ver mais” com contraste insuficiente no estado normal, comprometendo a sua identificação como elementos clicáveis

  Recomendação
  Melhorar o contraste e o destaque dos botões no estado normal, seja através de uma cor mais evidente, aumento da espessura do contorno ou outro reforço visual, garantindo que são facilmente reconhecidos como clicáveis sem depender do hover.

  Ponto 02
  Página: https://www.mun-celoricodebasto.pt/

  As setas de navegação do carrossel “Ver mais notícias” apresentam problemas de contraste devido à transparência aplicada no seu estado visual. Em determinados conteúdos de fundo, especialmente imagens mais claras ou complexas, os elementos tornam-se pouco percetíveis, dificultando a sua identificação como controlos interativos, sobretudo em dispositivos móveis.

  

  Figura 02 – Setas de navegação do carrossel com baixo contraste em alguns fundos.

  Recomendação
  Garantir contraste adequado das setas de navegação em todos os contextos visuais, reduzindo ou eliminando a transparência e assegurando a sua legibilidade independentemente do conteúdo de fundo. Pode-se também considerar o uso de fundos sólidos, sombras ou contornos para reforçar a visibilidade dos elementos.

  Ponto 03
  Página: https://www.mun-celoricodebasto.pt/

  Na secção “Outras notícias”, os cards apresentam imagens e conteúdos textuais totalmente clicáveis, incluindo a área do card como um todo.

  No entanto, não existe uma indicação visual consistente de interatividade nos elementos.

  A imagem não apresenta estados visuais (hover ou destaque) que indiquem que é clicável, e o texto associado encontra-se sublinhado, criando a perceção de que se trata de um link independente, quando na realidade todo o card funciona como um único elemento interativo.

  Esta inconsistência pode gerar confusão na perceção da estrutura e comportamento do conteúdo.

  

  Figura 04 – Cards da secção “Outras notícias” são clicáveis na totalidade, mas não apresentam indicação visual consistente de interatividade (hover/focus), o que pode gerar ambiguidade na perceção do elemento ativo.

  Outro exemplo
  https://www.mun-celoricodebasto.pt/visite-celorico/capital-das-camelias/

  Recomendação
  Garantir consistência na indicação de elementos clicáveis, aplicando um padrão único de interação ao card completo (imagem e texto), incluindo estados de hover e foco visíveis.

  Deve ser evitada a utilização de estilos que sugiram múltiplos elementos interativos dentro do mesmo bloco, assegurando uma perceção clara e uniforme da área clicável.

  Ponto 04
  Página: https://www.mun-celoricodebasto.pt/municipio/freguesias-do-concelho/

  Os ícones de redes sociais não aparentam ser elementos clicáveis. Apesar de serem interativos, não existe feedback visual claro em estado normal ou de hover que comunique a sua funcionalidade, o que pode dificultar a perceção de interação por parte do utilizador.

  

  Figura 05 – Ícones de redes sociais são clicáveis, mas não apresentam indicação visual consistente de interatividade (hover/focus), o que pode dificultar a perceção de que são elementos acionáveis.

  Outros exemplos
  https://www.mun-celoricodebasto.pt/3o-passeio-extreme-dos-azelhas-voltou-a-atrair-apaixonados-pelo-desporto-motorizado/
  https://www.mun-celoricodebasto.pt/municipio/
  https://www.mun-celoricodebasto.pt/municipio/mensagem-do-presidente/
  https://www.mun-celoricodebasto.pt/municipio/camara-municipal/reunioes-de-camara/

  Recomendação
  Recomenda-se adicionar feedback visual de hover e foco aos ícones de redes sociais (ex.: alteração de cor, contraste ou escala), de forma a reforçar a perceção de interatividade e melhorar a acessibilidade.

  Ponto 05
  Página: http://mun-celoricodebasto.pt/visite-celorico/onde-ficar/#cat-111-info

  Na página, os filtros de categorias (“Todos”, “AL”, “Camping”, “TER”, “TH”, “Hotel”) são apresentados com aparência de texto comum, embora sejam elementos interativos de filtragem.

  Esta apresentação não fornece indicação visual clara de que se tratam de elementos clicáveis, o que pode dificultar a perceção da sua funcionalidade por parte do utilizador.

  

  Figura 06 – Filtros de categorias apresentados como texto simples, embora sejam elementos interativos de filtragem, sem indicação visual consistente de interatividade ou estado ativo.

  Recomendação
  Recomenda-se reforçar a affordance visual dos elementos de filtragem, garantindo que estes são facilmente identificáveis como interativos. Para tal, devem ser aplicados estilos consistentes de interação, como alteração de cor, sublinhado, destaque de fundo ou outros efeitos visuais em estado de hover, foco e estado ativo.

  Adicionalmente, o estado selecionado deve ser claramente distinguível dos restantes, de forma a melhorar a compreensão da navegação e a experiência de utilização.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #44 Existem formulários longos sem divisão por passos

  etiqueta: chk transaçãoetiqueta: R 1.2etiqueta: NOK

  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

  Em formulários longos, com mais de 2 ecrãs de altura, deve-se garantir que a informação é pedida ao utilizador de forma faseada, dividindo os passos em várias páginas ou secções. No caso de formulários curtos, não é necessário fazer esta divisão.

  Nos formulários das páginas Radar Social, Inquéritos de Satisfação (quer o formulário dentro do acordeão “Inquérito aos Turistas” quer o formulário dentro do acordeão “Inquérito aos Habitantes”) e Apoio ao Empresário/Investidor (dentro do acordeão “Bolsa de Emprego”), é pedida toda a informação ao utilizador de uma só vez.

  Recomendamos que seja revista a estrutura dos formulários mais longos, de forma a segmentar os passos em várias páginas ou secções.

  

  Figura 1 - Formulário dentro do acordeão "Inquérito aos Turistas" da página Inquéritos de Satisfação.

  

  Figura 2 - Formulário "Formulário de Sinalização" da página Radar Social. O formulário está destacado através de um retângulo de borda preta.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #45 Botões de controlo do formulário inacessíveis por leitor de ecrã

  etiqueta: chk transaçãoetiqueta: NOKetiqueta: 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

  Verificámos que, no formulário de vários passos da página Participe no futuro PDM, alguns botões de controlo não podem ser focados ou selecionados quando se utiliza um leitor de ecrã.

  No Passo 2, o botão “Seguinte”, que permite avançar para o Passo 3, não pode ser selecionado através das setas direcionais do leitor de ecrã. Da mesma forma, no Passo 3, o botão “Submeter” também não pode ser selecionado com o leitor de ecrã usando as setas direcionais.

  Recomendamos que os elementos <div> dentro dos quais estes elementos se encontram sejam apagados e que estes botões sejam desenvolvidos através do elemento semântico de HTML <button>, garantindo assim que possam ser corretamente focados e acionados por tecnologias de apoio.

  

  Figura 1 - Análise dos botões "Anterior" e "Seguinte", no Passo 2 do formulário da página Participe no futuro PDM, através do Google Inspector.

  

  Figura 2 - Análise dos botões "Anterior" e "Submeter", no Passo 3 do formulário da página Participe no futuro PDM, através do Google Inspector.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #60 O tamanho dos campos não reflete o tamanho previsível dos dados

  etiqueta: chk transaçãoetiqueta: R 2.1etiqueta: NOK

  O tamanho dos campos deve refletir o tamanho previsível dos dados.
  – ver requisito 2.1 na lista Transação

  A largura do próprio campo deve refletir o tamanho previsível dos dados a preencher, principalmente em campos de escrita livre em que o utilizador deve inserir os seus próprios dados.

  Os campos relativos ao contacto telefónico (“Telefone”, “Contacto Telefónico”, “Contacto Telefónico de um familiar/acompanhante”, “Telefone/Telemóvel”) têm a mesma largura que os campos “Nome”, por exemplo, sendo que, no contexto português, um número de telefone/telemóvel pode ter no máximo cerca de 14 caracteres (por exemplo, 00351212345678). Tendo isto em conta, este campo deveria ser mais curto.

  O mesmo se aplica aos campos “Email” (presente nos formulários das páginas Apoio ao Empresário/Investidor, Radar Social, Onde ficar, Participe no futuro PDM e no formulário Enviar Mensagem aberto através do link “Enviar mensagem” da página Executivo Municipal), “NIF” (presente no formulário da página Participe no Futuro PDM), “Idade” e “País de origem” (presentes no formulário dentro do acordeão “Inquérito aos Turistas” da página Inquéritos de Satisfação).

  Recomendamos a revisão dos campos dos formulários, garantindo que a largura dos campos está adequada ao tipo de informação a inserir.

  

  Figura 1 - Formulário da página Radar Social, onde os campos "Contacto Telefónico", "Email" e "Contacto Telefónico de um familiar/acompanhante" estão destacados através de retângulos de borda preta.

  

  Figura 2 - Formulário da página Participe no Futuro PDM onde os campos "NIF", "Telefone/Telemóvel" e "Email" estão destacados através de retângulos de borda preta.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #88 Campos com mais do que um rótulo

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

  As legendas dos campos são breves e claras.
  – ver requisito 2.3 na lista Transação

  Verificámos que no formulário “Enviar mensagem”, disponível quando se clica na hiperligação “Enviar mensagem” da página Executivo Municipal, há mais do que um rótulo a indicar o mesmo campo.

  Acima dos dois campos de input destinados ao primeiro e ao último nome surge o rótulo “Nome (obrigatório)”. No entanto, por baixo de cada um desses campos aparecem também os rótulos “Primeiro” e “Último”.

  O mesmo acontece na página Participação do futuro PDM com os rótulos “Morada completa”, “Endereço”, “Localidade” e “Código postal”.

  Recomendamos que cada campo tenha apenas um rótulo. Esse rótulo deve estar posicionado acima do campo de input, tal como acontece com os restantes campos do formulário. No primeiro caso, uma possível solução seria utilizar os rótulos “Primeiro Nome” e “Último Nome”, respetivamente, para identificar claramente cada campo. No segundo caso, uma possível solução seria utilizar os rótulos “Morada/Rua” e “Localidade” e “Código postal”, respetivamente.

  

  Figura 1 - Análise dos campos para inserção do nome, no formulário "Enviar Mensagem", através do Google Inspector.

  

  Figura 2 - Análise dos rótulos "Morada completa", "Endereço", "Localidade" e "Código postal", no formulário da página Participação do futuro PDM, através do Google Inspector.

• evidência: issue #71 Opções de radio buttons com siglas sem significado explícito

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

  As legendas dos campos são breves e claras.
  – ver requisito 2.3 na lista Transação

  No formulário da página Onde Ficar, verificámos que algumas opções do campo “Tipologia” são apresentadas apenas sob a forma de acrónimos — “TER”, “TH”, “AL” e “CC”. Para muitos utilizadores, especialmente aqueles que não estão familiarizados com estas designações, estes acrónimos podem não ser compreensíveis.

  Recomendamos que seja fornecido o significado destes acrónimos por extenso (por exemplo, “TER - Turismo em Espaço Rural”, “TH - Turismo de Habitação”, etc.)

  

  Figura - Formulário da página Onde Ficar. O campo "Tipologia" está destacado através de um retângulo de borda preta.

• evidência: issue #67 Caixas de seleção e radio buttons sem rótulo anunciado ao receber foco

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

  As legendas dos campos são breves e claras.
  – ver requisito 2.3 na lista Transação

  Verificámos que, nos formulários que utilizam caixas de seleção (checkboxes) e radio buttons, os respetivos rótulos não são anunciados quando o utilizador navega com Tab ou Shift+Tab. Isto pode ser especialmente confuso para utilizadores que navegam pela página através de tecnologias de apoio.

  Recomendamos que a estrutura destes campos seja restruturada. Deve ser criado um elemento <fieldset> que contenha todas as caixas de seleção / radio buttons. Dentro deste elemento <fieldset>, o elemento <legend> deve conter o rótulo do grupo (por exemplo, “Como avalia a gestão de resíduos no município?”).

  Podem consultar o artigo da WebAIM Creating Accessible Forms, nomeadamente o conteúdo abaixo dos cabeçalhos de nível 2 “Checkboxes” e “Radio Buttons”, para mais informações.

  URL’s a verificar:

  • https://www.mun-celoricodebasto.pt/viver/investir/apoio-ao-empresario-investidor/
  • https://www.mun-celoricodebasto.pt/viver/desenvolvimento-social-e-saude/desenvolvimento-social/radar-social/
  • https://www.mun-celoricodebasto.pt/sustentabilidade/destino-turistico-sustentavel/
  • https://www.mun-celoricodebasto.pt/visite-celorico/onde-ficar/#cat-109-info
  • https://www.mun-celoricodebasto.pt/viver/planeamento-territorial-e-gestao-urbanistica/planos-e-programas-de-ordenamento-do-territorio/pdm-plano-diretor-municipal/participe-no-futuro-pdm/
  • https://www.mun-celoricodebasto.pt/viver/ambiente-e-recursos-naturais/papersu-2030/

  

  _Figura 1 - Navegação pelo formulário da página Apoio ao Empresário/Investidor através do teclado (Tab e Shift+Tab) e do leitor de ecrã NVDA. Leitura que o leitor de ecrã faz do campo "Carta de condução" está destacada através de um retângulo de borda preta.

  

  Figura 2 - Navegação pelo formulário da página Radar Social através do teclado (Tab e Shift+Tab) e do leitor de ecrã NVDA. Leitura que o leitor de ecrã faz do campo "Escolha o(s) motivo(s) da sinalização" está destacada através de um retângulo de borda preta.

• evidência: issue #64 Há campos com rótulos incorretos / trocados

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

  As legendas dos campos são breves e claras.
  – ver requisito 2.3 na lista Transação

  No formulário da página Inquéritos de Satisfação, dentro do acordeão “Inquérito aos Habitantes”, identificámos um erro na associação entre rótulos e opções de resposta.

  O campo “Género” apresenta opções que correspondem a faixas etárias (“<18 anos”, “18-25 anos”, “26-35 anos”, entre outras). Por sua vez, o campo “Idade” apresenta opções que correspondem a identidades de género (“Masculino”, “Feminino”, “Outro” e “Prefiro não dizer”).

  Esta troca de rótulos compromete a compreensão do formulário e pode causar confusão em utilizadores com deficiências cognitivas ou que dependem de tecnologias de apoio, como leitores de ecrã, para navegarem na página.

  Recomendamos que cada conjunto de opções seja corretamente associado ao respetivo campo:

  • O campo “Idade” deve apresentar as faixas etárias (“<18 anos”, “18-25 anos”, “26-35 anos”, etc.).
  • O campo “Género” deve apresentar as opções “Masculino”, “Feminino”, “Outro” e “Prefiro não dizer”.

  

  Figura 1 - Formulário da página Inquéritos de Satisfação onde os rótulos dos campos "Género" e "Idade" estão trocados. Os rótulos dos campos estão destacados através de retângulos de borda preta.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk transaçãoetiqueta: R 2.4etiqueta: NOK

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

  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 no início do formulário.

  Verificámos que, à frente do rótulo “Privacidade e RGPD” da página PAPERSU 2030, está um asterisco (“*”).

  No entanto, não é fornecida uma legenda clara sobre o significado do asterisco no formulário. Posto isto, recomendamos que seja adicionada uma legenda no início do formulário que indique claramente o significado de *.
  Uma outra possível solução é adicionar a descrição “(obrigatório)” ou “(campo obrigatório)” em frente aos rótulos dos campos obrigatórios.

  

  Figura - Campo "Privacidade e RGPD", no formulário da página PAPERSU 2030, onde não há indicação clara do significado do asterisco ("*").

• evidência: issue #78 Há campos obrigatórios que não estão identificados programaticamente

  etiqueta: chk transaçãoetiqueta: melhoriaetiqueta: R 2.4

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

  Há campos obrigatórios que não estão identificados programaticamente

  Verificámos que, em alguns campos dos formulários do site da Câmara Municipal de Celorico de Basto, existem campos que apresentam a indicação visual “Obrigatório” junto ao respetivo rótulo, mas que não estão programaticamente definidos como obrigatórios.

  Recomendamos, em todos os campos obrigatórios, que, para além do texto “Obrigatório” em frente ao rótulo do campo, seja também adicionado o atributo required nos campos de input de forma a reforçar aos utilizadores de tecnologias de apoio que o campo em questão é um campo de preenchimento obrigatório.

  Exemplo de campos e páginas a verificar:

  Apoio ao Empresário/Investidor - Campos:

  • “Carta de Condução”
  • “Escolha uma opção”
  • “Nestas condições, autorizo a utilização e divulgação dos meus dados:”
  • “Consentimento”

  Inquéritos de satisfação – formulário dentro do acordeão “Inquérito aos Turistas” - Campos:

  • “Qual é o seu principal motivo para visitar este destino?”
  • “Como é que teve conhecimento do nosso destino?”
  • “Onde está hospedado?”
  • “Como é que avalia a infraestrutura e os serviços turísticos do destino? (transporte, alojamento, alimentação, guias turísticos, etc.)”
  • “Que atividades realizou durante sua visita?”
  • “Como classifica a sua experiência em Celorico de Basto?”
  • “Foram percetíveis esforços visíveis de sustentabilidade durante sua visita? (ex. reciclagem, utilização de energias renováveis, preservação de áreas naturais)”
  • “Acredita que o destino está a contribuir positivamente para a preservação ambiental?”
  • “Como classificaria a conscientização ambiental e a educação no destino? (ex. sinalização, informação disponível, atividades educativas)”
  • “Teve a oportunidade de interagir com a comunidade local?”
  • “Como classifica a autenticidade e a preservação da cultura local no destino?”
  • “Avalie a hospitalidade dos habitantes?”
  • “Recomendaria este destino a outras pessoas?”

  Onde ficar - Campos:

  • “Pretende/deseja:”
  • “Privacidade”

  

  Figura 1 - Análise do campo "Carta de Condução", no formulário da página Apoio ao Empresário/Investidor, através do Google Inspector.

  

  Figura 2 - Análise do campo "Pretende/deseja", no formulário da página Onde ficar, através do Google Inspector.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #12 Ausência de feedback em ações de longa duração

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

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

  Notas Gerais

  • Em ações de submissão ou processamento, o sistema deve fornecer feedback adequado ao utilizador, garantindo que este compreende que a operação está a decorrer.
  • A ausência de feedback em ações potencialmente demoradas pode gerar incerteza e levar o utilizador a repetir a ação ou a considerar que ocorreu um erro.

  URL a verificar

  • https://www.mun-celoricodebasto.pt/

  Evidências:

  Ao desencadear a ação de pesquisa, o sistema não apresenta qualquer indicador de progresso. O tempo de resposta da operação é de aproximadamente 6 segundos, período durante o qual a interface permanece estática, sem comunicar ao utilizador que a informação está a ser processada.

  

  Figura 1 – Ausência de indicador de processamento durante os 6 segundos de espera da pesquisa

  Recomendações:

  • Implementar indicador visual: Adicionar um spinner ou ícone de carregamento imediato logo após o envio do formulário de pesquisa.
  • Notificação semântica: Utilizar um contentor com aria-live="polite" ou role="status" contendo uma mensagem textual (ex: "A pesquisar, por favor aguarde..."). Isto garantirá que utilizadores de leitores de ecrã também sejam informados sobre o estado da operação.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #13 Feedback após submissão não acessível

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

  Deve ser confirmado o sucesso da transação/envio de informação.
  – ver requisito 3.2 na lista Transação

  Notas Gerais

  • Sempre que o utilizador realiza uma ação (ex.: submissão de um formulário ou envio de feedback), o sistema deve fornecer um retorno claro e imediato sobre o resultado dessa ação. Esse feedback deve ser perceptível visualmente e também programaticamente acessível, garantindo que utilizadores de tecnologias de apoio são informados da alteração de estado.

  Evidências:

  Caso 1 – Componente de feedback (“A informação desta página foi útil?”)

  • https://www.mun-celoricodebasto.pt/municipio/
  • https://www.mun-celoricodebasto.pt/transparencia/
  • (outras páginas com o mesmo componente)

  No componente de feedback “A informação desta página foi útil?”, após o utilizador submeter a resposta:

  • É apresentada uma mensagem visual (“reação adicionada”)
  • No entanto, essa mensagem não é anunciada por tecnologias de apoio
  • Utilizadores de leitores de ecrã não recebem qualquer indicação de que a ação foi concluída
  • Não existe mecanismo (ex.: aria-live, role="status") que torne esta atualização programaticamente determinável

  Este comportamento pode levar à incerteza sobre o sucesso da ação para utilizadores que não dependem de feedback visual.

  

  Figura 1 – Mensagem “reação adicionada” apresentada apenas visualmente, sem anúncio para tecnologias de apoio

  ---

  Caso 2 – Formulário “Enviar mensagem” (modal)

  • https://www.mun-celoricodebasto.pt/municipio/camara-municipal/executivo-municipal/ (enviar mensagem)

  Ao submeter o formulário:

  • A modal é fechada automaticamente
  • Não é apresentada qualquer mensagem de sucesso visível persistente
  • Não existe feedback programaticamente acessível
  • O utilizador perde o contexto da ação

  Isto impede a perceção do resultado da submissão.

  

  Figura 2 – Submissão do formulário fecha a modal sem feedback acessível

  ---

  Caso 3 – Feedback após submissão não acessível por teclado nem leitor de ecrã

  Após a submissão de formulários:

  • A mensagem de feedback não é anunciada por leitores de ecrã
  • Não existe uso de aria-live, role="alert" ou role="status"
  • O foco não é movido para a mensagem
  • A mensagem não é alcançável por navegação por teclado
  • O utilizador pode permanecer no formulário sem perceber que a ação foi concluída

  Este comportamento compromete a compreensão do estado da interface.

  

  Figura 3 – Mensagem de feedback não anunciada nem acessível por teclado

  Recomendações

  • Garantir que todas as ações apresentam feedback claro e acessível
  • Utilizar aria-live="polite" ou role="status" para mensagens dinâmicas
  • Mover o foco para a mensagem de sucesso/erro após submissão
  • Assegurar que o feedback é navegável por teclado
  • Garantir que mensagens são visíveis e persistentes
  • Evitar fechar modais automaticamente sem feedback
  • Validar com leitores de ecrã e navegação por teclado

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #74 Não existem formulários que permitam ações destrutivas pelo utilizador

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

  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

  Não identificamos formulários que permitem o utilizador fazer ações destrutivas e por esse motivo, consideramos esse critério como "Não aplicável".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #76 Transação - Existem formulários sem Mensagens de erro junto aos campos

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

  As mensagens de erro são claramente identificadas junto aos campos de origem.
  – ver requisito 4.3 na lista Transação

  Os campos “Endereço” e “Localidade” do formulário Onde ficar não apresenta mensagens de erro na sua vizinhança:

  

  Campos endereço e localidade do formulário da página Onde ficar sem mensagens de erro na vizinhança
  Na vizinhança do campo “Código postal” existe uma mensagem de erro que refere os três campos do agrupamento morada e está programaticamente associada a eles, pelo que os leitores de ecrã anunciam essa mensagem ao navegar por teclado (tab e shift+tab).
  No entanto, ao navegar pelo formulário utilizando o modo de navegação dos leitores de ecrã, a mensagem de erro só é anunciada após ser lido o campo “Código postal”.

  Recomendamos que sejam apresentadas mensagens de erro junto aos campos de todos os formulários, para que sejam anunciadas individualmente pelos leitores de ecrã a seguir à leitura de cada campo, independentemente do modo de navegação utilizado. Assim, a mensagem que abrange os três campos do agrupamento morada deve ser dividida em três mensagens individuais, uma para cada campo deste agrupamento.
  As três mensagens devem ser programaticamente associadas aos respetivos campos, tal como estava a ser realizado relativamente à mensagem a substituir.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #85 As mensagens de erro não ajudam na resolução do problema

  etiqueta: chk transaçãoetiqueta: NOKetiqueta: 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

  Os campos dos formulários devem devolver mensagens de erros explícitas sobre como resolver o problema identificado em cada campo. Essas mensagens devem ser comunicadas visualmente e pelo leitor de ecrã.
  Verificámos que na página Inquéritos de Satisfação, no formulário dentro do acordeão “Inquérito aos TURISTAS”, as mensagens de erro não são explícitas, não oferecendo qualquer tipo de sugestão ou ajuda no preenchimento.
  Recomendamos a revisão do formulário desta página para garantir que as mensagens de erro apresentadas junto aos campos sejam realmente úteis para a resolução de problemas. Essas mensagens devem explicar de forma clara o que está incorreto e indicar os passos necessários para o corrigir. No caso do campo “Idade”, por exemplo, a mensagem pode informar que é necessário indicar a idade quando o campo está vazio ("Por favor, indique a sua idade."), ou pode esclarecer que apenas dígitos devem ser utilizados quando o valor introduzido não é numérico ("A idade deve ser um número.", Ou "A idade deve ser um número inteiro, sem símbolos ou letras".

etiqueta: OK (no entanto contém 4 melhorias que se recomenda efetuar)

Lista de evidências recolhidas:

• evidência: issue #86 Outras Violações - Conteúdos da Revista Municipal inacessíveis com a ferramenta DearFlip

  etiqueta: melhoriaetiqueta: outras violações

  A página da Revista Municipal apresenta conteúdos inacessíveis devido à utilização do visualizador DearFlip, que não permite a navegação por teclado nem o acesso adequado por leitores de ecrã.

  Na página Revista Municipal existem conteúdos inacessíveis disponibilizados através da ferramenta externa DearFlip (dearflip.com). A navegação pelos conteúdos da revista municipal 2024, 2023, 2022 e 2020 são inacessíveis via teclado e para tecnologias de apoio, como leitores de ecrã.

  O foco de navegação permanece fixo no campo de paginação, nomeadamente apenas no controlo de páginas, não permitindo ao utilizador explorar o conteúdo da revista. Nem aceder a opção “Download PDF file” (Figura 1 e 2)

  

  Figura 1 - Revista Municipal inacessível para tecnologias de apoio

  

  Figura 2 - Opções para descarregar ficheiro PDF, está em inglês e disponível apenas na navegação com o rato

  Além disso, um utilizador com deficiência visual não consegue perceber que o conteúdo é apresentado em formato de duas páginas em simultâneo, nem aceder à informação publicada na revista, uma vez que o conteúdo visual não é exposto de forma semântica nem navegável.

  Embora seja possível descarregar a revista em formato PDF e seja possível extrair o respetivo texto do conteúdo, só é possível essa interação com o rato.

  Recomendação de melhoria
  Recomenda‑se a substituição ou complementação do visualizador DearFlip por uma solução acessível, garantindo que os conteúdos da Revista Municipal sejam disponibilizados em formatos navegáveis por teclado e compatíveis com leitores de ecrã, preferencialmente em HTML semântico.

• evidência: issue #70 Outras Violações - Botão com texto alternativo em inglês

  etiqueta: melhoriaetiqueta: outras violações

  Verificamos uma inconsistência linguística, uma vez que o site está em português mas há componente com o textos alternativos em inglês.

  Por exemplo na página Freguesias do Concelho os botões das redes sociais possuem textos alternativos em inglês "Share on facebook", “Share on x-twitter”, "Share on linkedin", "Share on email" e "Share on pinterest, sem indicação adequada do atributo lang. (Figura 1)

  

  Figura 1 - Textos alternativos em inglês em análise com leitor de ecrã NVDA

  Esta implementação dificulta a navegação para utilizadores do idioma português e com tecnlogias de apoio, pois o leitor de ecrã anuncia os botões em inglês.

  O mesmo acontece no Mapa interativo do evento "Festa Internacional das Camélias" onde existem botões com textos apresentados em dois idiomas. Um exemplo é o botão identificado como “Direção/Directions”, que mistura português e inglês no texto visível. Além disso, os links não possuem texto alternativos para garantir acessibilidade aos utilizadores com tecnologias de apoio. (Figura 2)

  

  Figura 2 - Botões com textos em dois idiomas

  Essa prática pode gerar confusão para utilizadores de leitores de ecrã e outras tecnologias assistivas, além de comprometer a consistência do idioma principal da página.

  Recomendação de melhoria

  • Recomendamos traduzir todos os textos alternativos dos botões para português, idioma em que o website está implementado.

  • Garantir que o texto visível e o texto alternativo (aria-label ou equivalente) dos botões estejam exclusivamente no idioma principal da página (português), conforme definido no atributo lang. Evitar a mistura de idiomas no mesmo rótulo de botão ou elemento interativo.

  • Caso haja necessidade de oferecer conteúdo multilíngue, implementar um mecanismo claro de seleção de idioma, assegurando que todo o conteúdo, seja atualizado de forma consistente.

• evidência: issue #63 Outras violações - Conteúdos com código HTML visível no corpo de texto

  etiqueta: melhoriaetiqueta: outras violações

  Foram identificados conteúdos com código HTML visível no corpo de texto, o que indica falhas na renderização ou na formatação do conteúdo editorial.

  Na página do evento Caminhada Rota do Mel, foi identificado especificamente um problema no link do formulário, que está mal formatado com código HTML disponível com o atributo <a> no corpo de texto, afetando a navegação e podendo impedir o acesso correto ao formulário. (Figura 1)

  

  Figura 1 - Link do formulário em código HTML no corpo de texto

  Na página Mapa do Site, surgem elementos de marcação HTML expostos ao utilizador final, com o código [wp_sitemap_page only=”page”] comprometendo a legibilidade e a compreensão da informação apresentada. (Figura 2)

  

  Figura 2 - Mapa do site encontra-se desformatado no corpo de texto

  Estas situações prejudicam a experiência do utilizador, reduzem a credibilidade do site institucional e podem criar barreiras de acesso à informação, nomeadamente para utilizadores com tecnologias de apoio.

  Recomendação de Melhoria
  Corrigir a formatação dos conteúdos, garantindo que todo o código HTML é corretamente interpretado pelo sistema e não exposto no texto visível. Rever e testar o links disponíveis nas páginas, assegurando que está funcional, devidamente formatado e acessível.

• evidência: issue #57 Outras Violações - Data da secção lateral informativa incoerente com o conteúdo e imagem do evento

  etiqueta: melhoriaetiqueta: outras violações

  Na página do evento “Feira da Saúde”, existe uma inconsistência entre a informação apresentada no conteúdo principal e a informação exibida na secção lateral informativa (sidebar). (Figura 01)

  

  Figura 1 - Inconsistência da informação sobre a data e horário do evento

  • O conteúdo principal e a imagem do evento indicam claramente que a iniciativa decorre nos dias 21 e 22 de maio.
  • Contudo, na secção lateral, o campo “Data” apresenta o período “02 - 30 Abr 2026” e o estado “A decorrer…”, o que não corresponde às datas reais do evento.

  Esta discrepância pode gerar confusão nos utilizadores, prejudicar a confiança na informação disponibilizada e levar a interpretações erradas sobre a calendarização do evento (ex.: assumir que o evento está a decorrer durante todo o mês de abril).

  Recomendação de Melhoria
  Alinhar a data e horário apresentada na secção lateral com as informações efetivas do evento indicadas no conteúdo principal. Garantir que todos os módulos informativos da página (conteúdo, imagem promocional e sidebar) são alimentados pela mesma fonte de dados ou validados em conjunto antes da publicação.

  • Rever o estado do evento (“A decorrer…”) para refletir corretamente a sua situação real (ex.: “Agendado” ou “Evento futuro”), melhorando a clareza informativa e a experiência do utilizador.