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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #39 O menu principal não está estruturado corretamente como lista

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.1

  Quando navegamos com o leitor de ecrã pelas subopções de “Institucional”, o leitor anuncia que as opções estão dentro de “grupos”, não existindo qualquer indicação de que se trata de uma lista de opções ou a informação sobre o número de opções disponíveis:

  
  

  Isso ocorre porque, apesar de estarem a utilizar a semântica de lista com ul e li, foi utilizado atributos como o role="menu",role="menubar", role="menuitem" e aria-haspopup que alteram a semântica nativa desses elementos. Como consequência, as tecnologias de apoio deixam de os reconhecer como uma lista, passando a interpretá‑los como componentes de menu:

  
  

  URL

  • https://cm-camaradelobos.pt/

  Sugestão de correção

  • Remover os atributos role="menu",role="menubar", role="menuitem" e aria-haspopup de todas as opções do menu desktop e mobile.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #71 Não é possível navegar para a opção seguinte do menu sem percorrer as subopções

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 1.2

  No menu mobile, quando se navega pelas opções com o leitor de ecrã e com o teclado, as subopções são automaticamente apresentadas ao utilizador. Isso obriga o utilizador a percorrer todas as opções e respetivas subopções até encontrar a desejada, não permitindo saltar diretamente entre as opções de 1.º nível:

  

  URL

  • https://www.cm-camaradelobos.pt/ - menu mobile

  Sugestão de correção

  • As opções devem abrir/fechar conforme escolha do utilizador. Para isso, é necessário implementar um evento em conjunto com o aria-expanded gerenciar a abertura e fecho das subopções.

• evidência: issue #70 Não é possível identificar opções que contém subopções com o leitor de ecrã

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

  Quando navegamos com o leitor de ecrã no menu lateral, não é possível identificar quais opções possuem subopções, uma vez que não é anunciado se estão abertas ou fechadas:

  

  Leitor de ecrã não informa se a opção está aberta ou fechada

  

  Na estrutura não é localizado o atributo aria-expanded

  ---

  Isso acontece também com o menu mobile, quando abrimos ou fechamos o menu não é indicado que ele aberto ou fechado:

  

  URL

  • Todas as páginas internas que apresentam o menu lateral
  • https://www.cm-camaradelobos.pt/institucional/camara-municipal/pelouros-municipais - menu lateral

  Sugestão de correção

  • Utilizar o atributo aria-expanded em conjunto com um script para gerenciar a abertura e fecho das opções.

• evidência: issue #68 O menu não está construído de forma apropriada

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

  No menu principal existem dois elementos interativos que, apesar de serem apresentados visualmente de forma separada, pertencem ao mesmo link. A imagem‑link “Assembleia Municipal Câmara de Lobos” utiliza como texto alternativo o conteúdo do texto span “Assembleia Municipal”. No entanto, esse texto está a ser apresentado como uma opção de 2.º nível do menu, enquanto a imagem surge como a última subopção desse mesmo grupo:

  
  

  Quando navegamos com o leitor de ecrã e o teclado, apenas o texto recebe o foco e a imagem é ignorada:

  

  ---

  Quando navegamos com o leitor de ecrã no menu desktop, são anunciadas opções que aparecem como “fechadas”, apesar de as respetivas subopções já estarem visíveis no ecrã. Por exemplo, ao navegar até à opção “Assembleia Municipal”, o leitor de ecrã indica que se trata de um item fechado, mesmo quando as suas subopções estão imediatamente apresentadas a seguir, não sendo necessária qualquer ação de abrir ou fechar:

  

  URL

  • https://www.cm-camaradelobos.pt/

  Sugestão de correção

  • A estrutura deve corresponder ao que é apresentado visualmente e para que não exista dois elementos interativos que direcionam o utilizador para o mesmo destino, recomendamos em manter o padrão que é feito nos outros grupos de opções, apresentando apenas o texto “Assembleia Municipal” como link. Nesse caso, a imagem‑link deve ser removida.
  • Devem utilizar o atributo aria-expanded apenas quando é necessária uma ação por parte do utilizador, como acontece nas opções de 1.º nível do menu. As subopções não requerem qualquer ação, uma vez que todas as opções já estão visíveis no ecrã. Por esse motivo, o atributo aria-expanded deve ser removido.

• evidência: issue #56 Não é possível fechar as opções do menu com o leitor de ecrã

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

  Quando abrimos uma opção do menu com o teclado, as suas opções são automaticamente fechadas quando o foco retorna para a opção de 1º nível. Contudo, essa construção gera problemas quando navega-se com o leitor de ecrã. Por exemplo, ao retornar a opção de 1º nível utilizando as setas direcionais (VO+setas direcionais) não é possível fechar a opção com o VO + Espaço ou o ENTER:

  

  Quando o foco retorna para a opção de 1º nível as subopções são automaticamente fechadas com o teclado

  

  Quando o foco do leitor de ecrã retorna para a opção de 1º nível as subopções continuam abertas e não é possível fecha-las com o VO + espaço e ENTER

  URL

  • https://cm-camaradelobos.pt/

  Sugestão de correção

  • As opções de 1º nível devem abrir ou fechar conforme a ação do utilizador.
  • Quando as subopções estiverem visíveis, deve ser possível voltar para a opção de 1º nível e fechá‑la utilizando as teclas VO + Espaço ou Enter.
  • Idealmente, podem incluir a tecla ESC como uma segunda alternativa para fechar as subopções.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #67 O menu mobile está com texto alternativo inapropriado

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.3

  Quando o menu mobile é aberto, a respectiva imagem do menu se altera para o fechar (X). No entanto, o seu nome acessível não se altera:

  

  ---

  Outro cenário acontece no menu, o leitor de ecrã está a anunciar o menu mobile como "Open mobile menu". Isso acontece porque o seu nome acessível está em inglês:

  

  URL

  • https://www.cm-camaradelobos.pt/ - menu mobile

  Sugestão de correção

  • Alterar o nome acessível para aria-label="Menu".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #52 Existência de multiplos h1 na página web

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.1

  Cada página do website deve conter um único elemento <h1>, que represente o título principal do conteúdo. A utilização de múltiplos <h1> pode comprometer a interpretação da hierarquia da página por tecnologias de apoio.

  Actuamente, todas as páginas apresentam o mesmo <h1> (Portal Municipal de Câmara de Lobos"). O elemento <h1> deve ser atribuídoao título principal de cada página de forma a identificar de forma clara o respetivo conteúdo.

  Na página de Declaração de Acessibilidade, verifica-se a existência de dois elementos <h1>, o que constitui uma utilização incorreta da estrutura de cabeçalhos.

  Esta duplicação introduz ambiguidade na identificação do título principal da página e prejudica a coerência da hierarquia semântica.

  

  Figura 1 - Identificação de dois cabeçalhos marcados com <h1> na mesma página. .

  

  Figura 2 - Exemplo do <h1> estar igual em todas as páginas .

  Recomendações

  • Garantir que existe um único elemento h1, correspondente ao título principal de cada página.
  • Em todas as páginas o título principal está sendo atribuído como h2 sendo necessário alterar para h1. Devem garantir que essa alteração não gere problemas na hierarquia entre os cabeçalhos.
  • Na página da Declaração de Acessibilidade, o título genérico "Portal Municipal de Câmara de Lobos" deve ser removido.

• evidência: issue #51 H1 não atribuído ao logo na homepage

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 2.1

  Na 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.

  Evidências

  

  Figura 1 - <h1> atribuído fora do logotipo .

  

  Figura 2 -Logótipo na homepage não marcado como <h1> .

  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 #80 Existem títulos que não estão estruturados como cabeçalhos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

  Foram identificados elementos que funcionam como títulos de secção, mas que se encontram marcados apenas com elementos <div> , <p> e <strong>, em vez de cabeçalhos apropriados.

  Nas páginas de notícias, os niveis de cabeçalhos estão incorretos. O cabeçalho "Notícias relacionadas" não está diretamente relacionado com o título da noticia em contexto, por isso, devem ambos ser <h2>.

  

  Figura 1 - Títulos de secção implementados com <p> e <strong> em vez de elementos de cabeçalho apropriados .

  

  Figura 2 - Títulos dos artigos da agenda implementados com <div> em vez de elementos de cabeçalho apropriados .

  

  Figura 3 - Exemplo de notícia .

  

  Figura 4 - Ferramenta web developer, onde vemos as "Notícias relacionadas" a um nível inferior ao título da notícia "Iniciativa “Vamos Falar de Livros - 12”" .

  URLs a verificar:

  https://cm-camaradelobos.pt/

  https://cm-camaradelobos.pt/informacoes/utilidades/noticias-de-camara-de-lobos/detalhe/3566-iniciativa-vamos-falar-de-livros-12-20260507122515 (rever todas as páginas de notícias)

  Recomendações

  • Nas páginas de notícias, alterar o nivel de cabeçalho das "Notícias relacionadas" para o mesmo do título da notícia em contexto, no exemplo dado, ambos deveriam ser <h2>

  • Substituir os elementos <p> utilizados como títulos de secção por elementos de cabeçalho semanticamente adequados.

  • Garantir que os níveis de cabeçalhos respeitam a hierarquia existente da página.

  • Recomenda-se a utilização de <h3> para todos os títulos de artigos na agenda.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #81 Não foram encontradas tabelas

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

  Evidências

  Não foram encontradas tabelas no website tornando esta issue N/A.

  Recomendações

  No response

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #82 Não foram encontradas tabelas

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

  Evidências

  Não foram encontradas tabelas no website tornando esta issue N/A.

  Recomendações

  No response

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #63 Existem etiquetas associadas a controlos escondidos das tecnologias de apoio

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

  Evidências

  No formulário da página notícias, as etiquetas “Categoria” e “Ano” estão associadas a controlos ocultos das tecnologias de apoio:

  

  Etiqueta Categoria associada a um elemento nativo, mas que está oculto das tecnologias de apoio
  Os campos “Categoria” e “Ano” são controlos personalizados, aos quais não está associada qualquer etiqueta.
  Possivelmente como forma de auxílio à submissão do formulário foram colocados controlos nativos <select>, mas que estão ocultos das tecnologias de apoio. Assim, as etiquetas não são anunciadas por estas tecnlogias quando se procede à navegação por teclado.
  Destacamos ainda que estes controlos personalizados não estão acessíveis para os utilizadores de leitores de ecrã, sendo impossível perceber qual a opção que está a ser selecionada.

  O mesmo problema ocorre também nos formulários das páginas multimédia e reels.
  No caso dos formulários FALAR COM O PRESIDENTE, OPINIÃO SOBRE OS PROJETOS MUNICIPAIS e ELOGIOS, RECLAMAÇÕES, INFORMAÇÕES E DÚVIDAS, o mesmo problema está presente, mas relativamente a campos <textarea>, em que foram criadas textareas personalizadas e incorretamente enriquecidas com acessibilidade, para além de não terem as etiquetas associadas (estão associadas às textareas nativas auxiliares em vez de estarem associadas às textareas personalizadas)

  Recomendações

  Recomendamos uma das seguintes alternativas:

  • A utilização de elementos combobox nativos, que já oferecem todos os mecanismos de acessibilidade, e a manutenção das etiquetas associadas a esses controlos nativos;
  • A restruturação das comboboxes editáveis presentes no site, de modo a torná-las acessíveis. Para tal, podem seguir o exemplo da W3C Editable Combobox With Both List and Inline Autocomplete. Nesse caso, não devem esquecer a verificação da associação das etiquetas aos controlos restruturados.
    No caso do problema verificado nas textareas, recomendamos a substituição das textareas personalizadas por textareas nativas, que já contêm os mecanismos de acessibilidade, não esquecendo de verificar a correta associação das labels.

• evidência: issue #45 Existem textos de etiquetas que não estão visíveis no ecrã

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

  Evidências

  A caixa de texto do formulário de Pesquisa tem uma etiqueta associada, mas o texto dessa etiqueta está oculto para todos os agentes:

  

  Campo de pesquisa com texto da etiqueta oculto
  Como se pode observar na figura, o texto da etiqueta do campo de pesquisa está num elemento label, ao qual é aplicada uma regra CSS que contém a propriedade “display: none”.
  Portanto, do ponto de vista de todos os utilizadores, é como se o campo de pesquisa não tivesse o elemento label associado.
  Quando cada campo tem uma etiqueta com texto visível e associada programaticamente a esse campo, é possível focar o campo ao clicar na etiqueta (ampliação da área de clique), o que pode beneficiar pessoas com dificuldades motoras ao selecionar um campo específico.
  Para além disso, quando se realiza a navegação por teclado (tab e shift+tab), os leitores de ecrã anunciam a legenda que está associada a cada campo, o que não acontece neste exemplo.

  Acresce ainda que o campo de pesquisa está rodeado por um elemento fieldset que tem um elemento legend com o texto “Search Form” que está visível apenas para os leitores de ecrã.
  O elemento fieldset não foi aplicado corretamente neste caso, pois o mesmo só deve ser aplicado em situações em que existem vários campos agregados ao mesmo conceito (por exemplo, uma morada que contenha vários campos para preenchimento, uma pergunta que necessite de uma resposta de entre várias disponíveis ou em que seja possível selecionar várias respostas, etc.).

  Recomendações

  Recomendamos a revisão dos formulários para garantir que a cada campo está associada uma etiqueta, e os textos de todas as etiquetas estejam visíveis no ecrã.
  Recomendamos ainda a remoção do elemento fieldset que está a envolver o campo de pesquisa do formulário em estudo, e consequente remoção do elemento legend que está encaixado nesse fieldset.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.2

  Evidências

  Verificámos que, em alguns campos dos formulários do Portal Municipal de Câmara de Lobos, existem campos de preenchimento obrigatório que não estão programaticamente definidos como tal.

  

  Figura 1 - Análise do campo "Declaro sob compromisso de honra a veracidade do reporte submetido e assumo toda a responsabilidade consequente de falsas declarações ou inexatidão", da página Falar com o Presidente, através do Google Inspector.

  

  Figura 2 - Análise do campo "Declaro ter conhecimento da política de privacidade da Câmara Municipal de Câmara de Lobos.", da página Opinião sobre os Projetos Municipais, através do Google Inspector.

  Para além disso, existem campos (por exemplo, no formulário da página Falar com o Presidente ) em que o atributo required tem uma sintaxe incorreta (foi utilizado required = "", em vez de required ou required = "true"), para além de quenão é necessário utilizar os dois atributos (required e aria-required) ao mesmo tempo.
  Acresce ainda que foram inseridos atributos aria-required = "true" em etiquetas, por exemplo, nas presentes no formulário da página Falar com o Presidente. Atributos required ou aria-required em etiquetas não têm qualquer efeito, bem pelo contrário, são semanticamente incorretos e dificultam a manutenção do site.

  

  Figura 3 - Etiqueta com o atributo aria-required

  Recomendações

  Recomendamos que, em todos os campos obrigatórios, seja 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:

  Falar com o Presidente
  Campos:

  • Descrição do Assunto
  • Declaro sob compromisso de honra a veracidade do reporte submetido e assumo toda a responsabilidade consequente de falsas declarações ou inexatidão
  • Declaro ter conhecimento da política de privacidade da Câmara Municipal de Câmara de Lobos.

  Opinião sobre os Projetos Municipais
  Campos:

  • Descrição da opinião
  • Declaro sob compromisso de honra a veracidade do reporte submetido e assumo toda a responsabilidade consequente de falsas declarações ou inexatidão
  • Declaro ter conhecimento da política de privacidade da Câmara Municipal de Câmara de Lobos.

  Elogios, Reclamações, Informações e Dúvidas
  Campos:

  • Descrição
  • Declaro sob compromisso de honra a veracidade do reporte submetido e assumo toda a responsabilidade consequente de falsas declarações ou inexatidão
  • Declaro ter conhecimento da política de privacidade da Câmara Municipal de Câmara de Lobos.

  Inscrições nas Reuniões de Câmara
  Campos:

  • Declaro sob compromisso de honra a veracidade do reporte submetido e assumo toda a responsabilidade consequente de falsas declarações ou inexatidão
  • Declaro ter conhecimento da política de privacidade da Câmara Municipal de Câmara de Lobos.

  Recomendamos ainda que seja verificada a sintaxe do atributo required nos elementos que já o têm, e que, no caso da existência dos atributos required e aria-required, permaneça apenas o atributo required.

  Finalmente, recomendamos a rmeoção de todos os atributos required e aria-required de todas as etiquetas (<label>).

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

  Evidências

  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 nos formulários das páginas Falar com o Presidente, Opinião sobre os Projetos Municipais, Elogios, Reclamações, Informações e Dúvidas e Inscrições nas Reuniões de Câmara não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

  

  Figura 1 - Formulário da página Falar com o Presidente. Não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

  

  Figura 2 - Formulário da página Inscrições nas Reuniões de Câmara. Não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

  Recomendações

  Recomendamos a revisão dos formulários de forma a ser adicionada uma legenda no início do formulário a indicar claramente o significado de *.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #69 Existem mensagens de erro apresentadas entre a etiqueta e o campo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.3

  Evidências

  Os formulários que precisam de apresentar mensagens de erro apresentam-nas junto aos campos. No entanto, existem campos cujas mensagens de erro associadas são apresentadas a seguir às labels em vez de serem as últimas componentes a serem apresentadas. Referimo-nos concretamente às textareas personalizadas do formulário presente na página OPINIÃO SOBRE OS PROJETOS MUNICIPAIS:

  

  Mensagem de erro apresentada a seguir à etiqueta

  Recomendações

  Recomendamos que as mensagens de erro sejam as últimas componentes dos campos a serem apresentadas, para manutenção da coerência com todos os outros controlos de formulários existentes no site. No caso tas textareas, deve ser anunciada etiqueta, em seguida o controlo (textarea) e finalmente a mensagem de erro.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #7 Imagem não decorativa com texto alternativo incorreto ou insuficiente

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

  Evidências

  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.

  

  ---

  Outro exemplo é o logo da Câmara de lobos. O texto alternativo não deve incluir a palavra “logo”, devendo limitar-se à identificação clara da entidade representada. Por exemplo: alt="Câmara de Lobos"

  

  URL:

  https://cm-camaradelobos.pt/
  https://cm-camaradelobos.pt/informacoes/utilidades/contactos

  Recomendações

  • As imagens não decorativas deverão ter uma descrição breve associada, nomeadamente através do uso do atributo alt descrevendo corretamente a imagem apresentada.

• evidência: issue #5 Imagem decorativa com texto alternativo indevido

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 5.1

  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 ou links acessíveis em texto. Nestes casos, as imagens podem ser tratadas como decorativas, devendo possuir alt="".

  

  URL:
  https://cm-camaradelobos.pt/
  https://cm-camaradelobos.pt/informacoes/utilidades/contactos
  https://cm-camaradelobos.pt/informacoes/utilidades/noticias-de-camara-de-lobos/detalhe/3559-cultura-nos-mercados-voltou-esta-manha-ao-mercado-do-estreito-de-camara-de-lobos-20260504161416
  https://cm-camaradelobos.pt/informacoes/utilidades/noticias-de-camara-de-lobos
  https://cm-camaradelobos.pt/servicos/urbanismo (imagem associada ao texto e sessão notícias)
  https://cm-camaradelobos.pt/informacoes/concelho/lobo-marinho
  https://cm-camaradelobos.pt/informacoes/concelho/caraterizacao-e-localizacao
  https://cm-camaradelobos.pt/servicos/social

  Recomendações

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #85 (Melhoria) Imagem sem descrição longa associada

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 5.2

  Evidências

  Verifica-se que as imagens de brasões são apresentadas apenas com um texto alternativo breve e genérico, que pode ser melhorado para transmitir os elementos visuais que compõem o símbolo heráldico. O alt atual identifica o brasão de forma geral, mas não descreve os seus componentes, cores, figuras, inscrições ou restantes elementos distintivos.

  Tratando-se de imagens informativas e visualmente compostas, a ausência de uma descrição longa associada compromete o acesso equivalente ao conteúdo por utilizadores de tecnologias de apoio. Nestes casos, o alt deve manter-se breve e identificativo, enquanto a descrição detalhada do brasão deve ser disponibilizada em formato acessível no conteúdo da página, associada à imagem sempre que necessário.

  

  URL

  https://cm-camaradelobos.pt/informacoes/concelho/freguesias/freguesia-de-camara-de-lobos

  Recomendações

  • A imagem deve ser acompanhado de uma descrição longa que pode ser associada via aria-labelledby, aria-describedby

• evidência: issue #31 O gráfico não é acompanhado de uma descrição longa

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.2

  Evidências

  Verifica-se que o gráfico é apresentado apenas como imagem, sem descrição longa ou alternativa textual associada que permita compreender a informação visual representada. O gráfico também não é alcançável por leitor de ecrã ou teclado, tornando a informação visual inacessível.

  

  ---

  As imagens relativas a revista PORTUGAL SOCIAL, são complexas e informativas, mas não possuem descrição suficiente para transmitir o conteúdo textual e visual nelas integrado. A alternativa disponível é insuficiente, comprometendo o acesso equivalente à informação.

  

  ---

  URL

  https://cm-camaradelobos.pt/institucional/transparencia-municipal/organizacao-e-funcionamento
  https://cm-camaradelobos.pt/servicos/social (imagem de entidades e empresas aderentes)
  https://cm-camaradelobos.pt/servicos/protecao-civil/servico-municipal-de-protecao-civil
  https://cm-camaradelobos.pt/servicos/protecao-civil/queimas-e-queimadas
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1462-6-a-edicao-do-premio-literario-joao-augusto-dornelas
  https://cm-camaradelobos.pt/servicos/desporto/lobos-park/cartazes-informativos/pt

  Recomendações

  • Recomenda-se que a informação representada no gráfico seja disponibilizada em formato acessível por tecnologias de apoio, garantindo que o conteúdo não dependa exclusivamente da imagem.
  • O gráfico deve ser acompanhado de uma descrição longa que pode ser associada via aria-labelledby, aria-describedby

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #6 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 descreve adequadamente o seu propósito (acesso à página inicial).

  

  ---

  Validado que a imagem link da Revista Viver Câmara de Lobos, 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. Também foi verificado que a imagem link não apresenta um texto alternativo suficiente que descreva a finalidade do link. por exemplo alt="Revista Viver Câmara de Lobos (abre num novo separador)"

  

  ---

  Verifica-se que, quando a galeria de imagens é aberta, as imagens apresentadas não dispõem de um texto alternativo adequado ao conteúdo efetivamente visível. O atributo alt utilizado na vista ampliada não descreve corretamente a imagem.

  

  ---

  As imagens link da sessão "Estamos ON" na homepage apresentam nome acessível genérico através do atributo alt(“CMCL1”). Para além disso, o nome acessível correto está sendo transmitido pelo title o que não é correto. O texto alternativo deve descrever corretamente a finalidade do link pelo atributo alt.

  

  URL

  https://cm-camaradelobos.pt/informacoes/documentos/todos-os-documentos?MjAyMS0yMDI1JmxldmVsMj0xOCZsZXZlbDM9MTE2
  https://cm-camaradelobos.pt/servicos/urbanismo
  https://cm-camaradelobos.pt/servicos/social/apoio-as-pessoas-em-situacao-de-sem-abrigo
  https://cm-camaradelobos.pt/informacoes/utilidades/noticias-de-camara-de-lobos/detalhe/3564-monitorizacao-e-acompanhamento-na-seara-velha-de-baixo-20260505164039

  Recomendações

  • O texto alternativo deve transmitir claramente o destino ou finalidade do link. Por exemplo: alt="Município de Câmara de Lobos – página inicial".
  • Não devem utilizar o title para transmitir o nome acessível do link. Esse atributo é utilizado apenas quando existe informação complementar que precisa ser anunciada.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #41 Contraste insuficiente em textos de Fluxograma

  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

  Na página Organização e funcionamento, verifica‑se a existência de texto normal apresentado em uma imagem de fluxograma, com contraste insuficiente em relação ao plano de fundo.

  O texto encontra‑se representado com a cor #FFFFFF (branco) sobre um plano de fundo com a cor #90BD22 (verde). Esta combinação apresenta uma taxa de contraste aproximada de 2,2:1, valor que não cumpre o requisito mínimo para texto normal. (Figura 1)



  

  Figura 1- Diagrama apresenta texto com taxa de contraste inferior ao recomendado

  O mesmo problema acontece com outros eixos do fluxograma, por exemplo nas combinação de cores #FFFFFF(cor de primeiro plano) e #0197C1(cor de plano de fundo). E nos textos #FFFFFF(branco) “Divisão de Obras Municipais e Conservação”, “Divisão de Gestão Administrativa” nas cores de fundo #1F8E61 e #EC3E36.

  Esta implementação impacta na acessibilidade da informação e pode dificultar significativamente a leitura do conteúdo por utilizadores com baixa visão, daltonismo comprometendo a perceção e compreensão da informação transmitida pelo diagrama.

  Recomendação de melhoria
  Recomenda‑se o ajuste da combinação de cores utilizada no texto ou no plano de fundo das referidas secções da imagem, de modo a garantir uma taxa de contraste mínima de 4,5:1 para texto normal.

  • Sempre que possível, evitar texto embutido em imagens e disponibilizar a informação em formato de texto HTML, permitindo melhor adaptação a tecnologias de apoio.

• evidência: issue #40 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 as ferramentas WAVE e Colour Contrast Analyser revelam problemas relacionados com insuficiência de contraste, afetando diretamente a legibilidade.

  Evidência 01:

  O website apresenta problemas de contraste na página para os textos normais das mensagens de erro dos Formulários de Participação, pois utilizam a combinação de cores #FF0302(cor de primeiro plano) e #FFFFFF(cor de plano de fundo). (Figura 1)

  

  Figura 1- Mensagens de erro em formulários com problemas de contraste

  Outros exemplos de formulários com problemas de contraste na mensagem de erro:


  • Falar com o Presidente
  • Opinião sobre os projetos municipais
  • Elogios, Reclamações, Informações e Dúvidas
  • Inscrições nas Reuniões de Câmara

  Evidência 02:
  No website, há textos normais que não possuem contraste suficiente em certos estados. Por exemplo, o menu principal do website, na opção “Participação” apresenta cards com textos no estado hover, que possuem um contraste inferior ao recomendado com a taxa de (4,3:1) (Figura 2)

  

  Figura 2 - Verificação do menu principal na página Pelouros Municipais não passa na combinação das cores #FFFFFF(cor de primeiro plano) e #5279BF(cor de plano de fundo).

  Evidência 03:
  Na página inicial, na secção “Agenda” os textos com as datas dos eventos, possuem um contraste inferior ao recomendado com a taxa de (2,1:1) (Figura 3)

  

  Figura 3 - Verificação das datas na secção "Agenda", não passam na combinação das cores #FFFFFF(cor de primeiro plano) e #E9A926(cor de plano de fundo).

  Recomendações Gerais
  Recomendamos a revisão das cores das páginas as combinações de cores utilizadas em texto normal incluindo estados de foco e hover para garantir os valores mínimos de contraste.

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

Lista de evidências recolhidas:

• evidência: issue #42 Texto grande não têm contraste suficiente em certos estados

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: 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

  • O contraste no texto grande (superior a 18 pontos ou superior a 14 pontos negrito) das páginas deve ser, no mínimo 3:1, para que as pessoas com baixa visão consigam ler o texto.

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

  O website apresenta problemas de contraste em alguns estados de hover de textos grandes, pois utilizam a combinação de cores #EAAA26(cor de primeiro plano) e #4870B6(cor de plano de fundo). Por exemplo na secção Câmara de Lobos Online e no link destaque do website (Figura 1 e 2)

  

  Figura 1 - Títulos grandes com problemas de contraste no estado de hover

  

  Figura 2 - Link destaque do website com problemas de contraste

  Recomendações
  Recomendamos a revisão das cores das páginas para garantir os valores mínimos de contraste do texto grande.

  Outras páginas OK na avaliação de contraste para textos grandes:



  • https://cm-camaradelobos.pt/servicos/ambiente
  • https://cm-camaradelobos.pt/informacoes/documentos/todos-os-documentos?MjAyMS0yMDI1JmxldmVsMj0xOCZsZXZlbDM9MTE2
  • https://cm-camaradelobos.pt/informacoes/utilidades/informacoes-gerais

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #79 Não foi 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

  Na secção multimédia da página inicial, verificou-se que não é possível ativar os controlos do player utilizando apenas o teclado.

  Para além disso, os controlos do vídeo apenas se tornam disponíveis através do rato, após o utilizador abrir o menu contextual com o botão direito e selecionar a opção “Show all controls”. O que não é intuitivo e poderá ter pessoas que desconhecem esse atalho.

  

  Figura 1 -Player da secção “Multimédia”, onde não foi possível pausar o vídeo utilizando o teclado .

  

  Figura 2 - Menu contextual com a opção "Show all controls".

  URLs a verificar:

  https://cm-camaradelobos.pt/

  Recomendações

  • Os controlos do player devem estar disponíveis de imediato, sem necessidade de recorrer ao menu contextual do botão direito do rato e selecionar a opção “Show all controls”.
  • Deve ser possível utilizar todos os controlos do player através do teclado, incluindo pausar e retomar a reprodução do vídeo.
  • O comportamento do player deve ser consistente com práticas comuns de acessibilidade presentes em players multimédia modernos, como o YouTube.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #78 Player sem legendas audiodescritivas

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 7.2

  Evidências

  Neste player do website são utilizadas as legendas automáticas do youtube, é recomendado que estas sejam substituídas por legendas audiodescritivas.

  

  Figura 1 - Legendas automáticamente geradas pelo Youtube .

  URLs a verificar:
  https://cm-camaradelobos.pt/informacoes/utilidades/noticias-de-camara-de-lobos/detalhe/3559-cultura-nos-mercados-voltou-esta-manha-ao-mercado-do-estreito-de-camara-de-lobos-20260504161416

  Recomendações

  • Adicionar legendas audiodescritivas.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #84 Botão sem função na versão móvel

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

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

  Notas Gerais

  Elementos interativos expostos na interface devem apresentar uma função claramente identificável, tanto visualmente como para tecnologias de apoio. A presença de controlos sem finalidade clara pode dificultar a compreensão da interface e a navegação

  URL a verificar

  • https://cm-camaradelobos.pt/
  • (todo website)

  Evidências

  Na versão móvel foi identificado um botão apresentado na interface através de um ícone gráfico, sem texto visível e sem nome acessível associado.

  Adicionalmente, o controlo surge exposto no interface sem que a sua finalidade seja claramente percetível para o utilizador.

  Como consequência, o utilizador pode não conseguir identificar a função do controlo nem distinguir a sua utilidade face aos restantes elementos de navegação.

  

  Figura 1 – Botão exposto na interface sem função claramente identificável

  Recomendações

  • Garantir que o controlo apresenta uma função clara e identificável.
  • Se o elemento tiver uma função válida, deve possuir:
    • nome acessível;
    • indicação clara da ação que executa.
  • Se o controlo não tiver utilidade efetiva para o utilizador naquele contexto, recomenda-se que não seja exposto na interface.
  • Validar com navegação por teclado e leitor de ecrã para confirmar que o controlo é compreensível e distinguível.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #86 Modal sem papel semântico de diálogo e sem nome acessível

  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, permitindo que tecnologias de apoio identifiquem corretamente quando um diálogo é aberto.
  • Para isso, a modal deve ser programaticamente identificável como diálogo e possuir um nome acessível que anuncie o contexto apresentado ao utilizador.
  • A ausência destes elementos dificulta a perceção da mudança de contexto e a compreensão da finalidade da janela modal.

  URL a verificar

  • https://www.cm-camaradelobos.pt/ (Modal da galeria/Instagram na homepage)

  Evidências

  Na homepage foi identificada uma janela modal da galeria implementada com elementos genéricos <div>, sem definição semântica de diálogo.

  O contentor principal da modal é apresentado como:

  <div id="ingallery-popup">

  No entanto:

  • não existe role="dialog" nem aria-modal="true";
  • a janela modal não possui nome acessível programaticamente determinável;
  • não existe associação a um título visível através de aria-labelledby;
  • também não existe alternativa com aria-label.

  Quando a modal é aberta, leitores de ecrã podem não anunciar corretamente que foi iniciado um novo contexto de interação.

  

  Figura 1 – Modal da homepage implementada sem semântica de diálogo e sem nome acessível

  Recomendações

  • A janela modal deve ser identificada programaticamente com role="dialog" (ou alertdialog, quando aplicável).
  • Deve ser definido aria-modal="true" quando a modal estiver ativa.
  • A modal deve possuir um nome acessível.
  • Sempre que exista título visível, esse título deve ser associado com aria-labelledby.
  • Quando não exista título visual, deve ser utilizado aria-label.
  • Deve ser validado que, ao abrir a modal, o leitor de ecrã anuncia corretamente o contexto do diálogo.

• evidência: issue #83 Foi identificado conteúdo informativo com estrutura tabular apresentado exclusivamente através de imagem

  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

  • Conteúdos com organização estrutural, como tabelas, cronogramas, organogramas ou esquemas informativos, devem ser disponibilizados com marcação HTML semântica adequada. Quando esse tipo de informação é apresentado apenas sob a forma de imagem, perde-se a possibilidade de identificação programática da estrutura e de navegação semântica por tecnologias de apoio.

  URL a verificar

  • https://www.cm-camaradelobos.pt/institucional/camara-municipal/regimento-e-funcionamento

  Evidências

  Neste caso, a informação visualmente organizada não é disponibilizada através de elementos semânticos equivalentes em HTML, como por exemplo tabelas (table, th, td) ou outra estrutura adequada ao conteúdo.

  Isto dificulta a perceção da organização da informação quando os estilos são removidos e impede também uma interpretação semântica adequada por leitores de ecrã.

  

  Figura 1 – Conteúdo estruturado apresentado apenas como imagem

  Recomendações

  • Sempre que a imagem represente informação estruturada, disponibilizar uma versão equivalente em HTML semântico.
  • Se o conteúdo tiver natureza tabular, utilizar estrutura de tabela HTML adequada.
  • Se não for possível substituir a imagem, garantir que a mesma informação está disponível em texto estruturado imediatamente antes ou depois da imagem.
  • O texto alternativo da imagem não deve substituir a estrutura do conteúdo quando existe informação complexa ou organizada.

• evidência: issue #55 O menu principal não está estruturado como uma navegação

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

  O menu principal não está estruturado como uma navegação utilizando a tag nav. Ao utilizar o leitor de ecrã, não é possível realizar saltos diretamente para o menu, nem este é identificado como uma área de navegação:

  
  

  URL

  • https://cm-camaradelobos.pt/

  Sugestão de correção

  • Inserir o menu principal dentro de uma tag nav. Essa alteração deve ser feita no menu desktop e mobile.

• evidência: issue #46 Elementos acionáveis implementados sem semântica adequada

  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
  Elementos que desencadeiam ações na interface, como abrir secções, expandir conteúdos ou ativar funcionalidades, devem ser implementados com elementos HTML semanticamente apropriados.

  A utilização de elementos genéricos para funções interativas dificulta a correta identificação desses controlos por tecnologias de apoio.

  URL a verificar

  • https://www.cm-camaradelobos.pt/
  • Controlos dos modais da galeria/Instagram na homepage
  • (verificar este padrão em todo o website)

  Evidências:
  Foi identificado um elemento com função de interação apresentado visualmente como acionável, mas implementado com um elemento genérico, sem semântica nativa de controlo interativo.

  Quando os estilos visuais são removidos, o elemento continua visível, mas deixa de ser claro programaticamente que se trata de um controlo acionável.

  Como consequência, utilizadores de tecnologias de apoio podem não identificar corretamente a sua função nem o reconhecer como elemento interativo.

  

  Figura 1 – Elemento acionável implementado sem semântica adequada

  Adicionalmente, foi identificado o mesmo padrão nos controlos da modal da galeria presente na homepage, nomeadamente nos elementos de fechar, navegação anterior e navegação seguinte.

  Esses controlos encontram-se implementados através de elementos genéricos (div) sem semântica nativa de controlo interativo, mantendo assim o mesmo problema de identificação programática e de reconhecimento semântico quando os estilos visuais são removidos.

  

  Figura 2 – Controlos da modal da homepage implementados com elementos genéricos sem semântica adequada

  Recomendações:

  Deve ser verificado este padrão em todo o website.

  • Elementos com comportamento interativo devem ser implementados com elementos HTML adequados, como <button> ou <a>.
  • A função do controlo deve ser identificável programaticamente.
  • Deve evitar-se o uso de elementos genéricos para ações interativas.
  • Deve ser validado que estes controlos continuam semanticamente percetíveis quando os estilos visuais são desativados.

• evidência: issue #33 Estrutura hierárquica de conteúdos sem semântica adequada

  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

  • Estruturas hierárquicas expansíveis, como árvores de navegação, categorias ou listas multinível, devem ser implementadas com elementos HTML semanticamente adequados ou com semântica ARIA apropriada.
  • A utilização exclusiva de elementos genéricos pode dificultar a perceção da estrutura, das relações hierárquicas e do estado expandido ou recolhido dos conteúdos.

  URL a verificar

  • https://www.cm-camaradelobos.pt/informacoes/documentos/todos-os-documentos
  • (outras páginas com componentes de navegação ou categorização semelhantes)

  Evidências:
  Foi identificada uma estrutura de navegação hierárquica apresentada visualmente como árvore expansível.

  Contudo, os itens da árvore encontram-se implementados com elementos genéricos, sem uma estrutura semântica que identifique programaticamente a hierarquia entre níveis nem os estados de expansão e recolha dos diferentes grupos.

  Quando os estilos visuais são removidos, a relação hierárquica entre os elementos deixa de ser claramente percetível, dificultando a compreensão da organização da informação.

  Como consequência, tecnologias de apoio podem não conseguir interpretar corretamente a estrutura do componente nem transmitir ao utilizador a organização e o estado dos conteúdos apresentados.

  

  Figura 1 – Estrutura hierárquica apresentada visualmente sem semântica adequada no HTML

  Recomendações:

  • Deve ser verificado este padrão em todo o website.
  • Estruturas hierárquicas devem ser implementadas com elementos HTML semanticamente adequados.
  • Os diferentes níveis de conteúdos devem ser identificáveis programaticamente.
  • Os estados expandido e recolhido dos elementos devem ser expostos de forma acessível.
  • Deve ser validado que a hierarquia continua percetível quando os estilos visuais são desativados.

• evidência: issue #32 Listagem de conteúdos sem estrutura semântica adequada

  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

  • Conjuntos de conteúdos relacionados, como listagens de documentos, notícias ou resultados, devem ser estruturados com elementos HTML semânticos apropriados (ex.: listas <ul> / <ol> e <li>), de forma a permitir que tecnologias de apoio identifiquem corretamente o agrupamento e o número de itens.
  • A utilização exclusiva de elementos genéricos (<div>) para representar estes conjuntos pode comprometer a perceção da relação entre os conteúdos apresentados.

  URL a verificar

  • https://www.cm-camaradelobos.pt/

  Evidências:

  Na página principal, têm várias secções em que cada item é apresentado como um conjunto de conteúdos relacionados (imagem, data, título, descrição e ligação para detalhe), estruturado com múltiplos elementos <div>.

  No entanto, estes itens não estão inseridos numa estrutura semântica de lista (<ul> / <li>), apesar de representarem claramente uma listagem de conteúdos homogéneos.

  

  Figura 1 – Listagem de eventos estruturada com elementos <div> sem utilização de lista semântica

  Como consequência, as tecnologias de apoio não conseguem identificar programaticamente que estes elementos pertencem a um conjunto, nem o número total de itens existentes.

  Quando os estilos CSS são desativados, os conteúdos passam a ser apresentados como blocos isolados, sem indicação clara da relação entre si, dificultando a compreensão da estrutura da informação.

  Recomendações:

  • Deve ser verificado este padrão em todo o website.
  • Os conjuntos de conteúdos que representem listagens (ex.: documentos, notícias, resultados) devem ser estruturados semanticamente como listas (<ul> ou <ol>), com cada item representado por um <li>.
  • Cada item da lista deve agrupar toda a informação relacionada (categoria, título, descrição e ações) dentro do respetivo <li>.
  • Evitar a utilização exclusiva de elementos genéricos (<div>) para representar agrupamentos de conteúdos.
  • Validar com leitores de ecrã para garantir que o agrupamento e o número de itens são corretamente anunciados.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #11 Conteúdos em componentes deslizantes permanecem ocultos quando os estilos são desativados

  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

  • Quando os estilos visuais são removidos, toda a informação relevante presente na página deve permanecer visível e disponível numa sequência lógica de leitura.
  • Componentes dinâmicos como sliders, carrosséis ou destaques rotativos não devem ocultar permanentemente conteúdos que façam parte da informação principal apresentada ao utilizador.

  URL a verificar

  • https://cm-camaradelobos.pt/

  Evidências:

  Na página inicial, alguns conteúdos apresentados em componentes deslizantes (slider/carrossel) encontram-se implementados com vários painéis no DOM, mas apenas o painel ativo permanece visível.

  Quando os estilos visuais são desativados, apenas o conteúdo do slide ativo continua disponível, enquanto os restantes conteúdos do mesmo componente permanecem ocultos.

  Como consequência, parte da informação relevante existente na página deixa de estar disponível numa apresentação linear sem CSS, o que dificulta a perceção integral do conteúdo e compromete o requisito 8.4 da checklist dos 10 aspetos.

  

  Figura 1 – Apenas o conteúdo do slide ativo permanece visível quando os estilos são desativados

  Recomendações:

  • Deve ser verificado este padrão em todo o website.
  • Os conteúdos apresentados em sliders ou carrosséis devem permanecer visíveis quando os estilos visuais são desativados.
  • Todos os painéis do componente devem continuar acessíveis numa sequência linear de leitura.
  • Os mecanismos de rotação automática devem afetar apenas a apresentação visual, não a disponibilidade do conteúdo.
  • Deve ser validado que títulos, descrições e ligações presentes nos vários painéis continuam disponíveis sem CSS.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #53 Quando a caixa de diálogo é aberta, o foco não move-se para um elemento dentro da caixa de diálogo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.1

  Evidências

  Validado que ao abrir a caixa de diálogo o cursor não se move pra dentro da caixa de diálogo. A modal não acessível às tecnologias de apoio.

  

  URL
  https://cm-camaradelobos.pt/

  Recomendações

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #54 O 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ã).

  

  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 #57 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 não está acessível às tecnologias de apoio, impedindo que a modal seja encerrada por leitor de ecrã ou teclado.

  

  URL:
  https://cm-camaradelobos.pt/

  Recomendações

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #58 Ao fechar a caixa de diálogo o foco não retorna ao elemento que o invocou.

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.4

  Evidências

  Validado que ao fechar a modal o foco não retorna ao elemento que o invocou.

  

  URL:
  https://cm-camaradelobos.pt/

  Recomendações

  • Recomenda-se que, ao fechar a modal, o foco seja devolvido ao elemento que a acionou.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #87 Ficheiros PDF apresentados em um domÍnIo diferente do domínio do website institucional

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 10.1

  Evidências

  Verifica-se que vários ficheiros PDF disponibilizados no website da Câmara Municipal de Lobos redirecionam para o domínio balcaomunicipal.cm. Recomenda-se que esses documentos sejam disponibilizados, no mesmo domínio do website institucional, de forma a garantir maior coerência na navegação e consistência na apresentação da informação.

  

  URL:

  https://balcaomunicipal.cm-camaradelobos.pt/templates/viewer/js/pdfjsv2/web/viewer.html?file=https%3A%2F%2Fbalcaomunicipal.cm-camaradelobos.pt%2Fdocumentos%2Fdl%2F%3Frefid%3D83oz1vxylo08o8k4804w%26bname%3D6f37f152d3d7e15a93ffd667fe179254%26cname%3Da896e47f64232fe7132125d976b2bf55579dd709e7d04265b5e0c031c238cfb980dcf1e7b6c2d3188a3c83b5c41ec638ef6f65c29b2a6e19f477ed8696943a1d

  https://cm-camaradelobos.pt/servicos/desporto/semana-do-desporto-de-camara-de-lobos

  Recomendações

  • Recomenda-se que os ficheiros atualmente alojados no domínio balcaomunicipal.cm sejam migrados ou disponibilizados diretamente no mesmo domínio do website institucional da Câmara Municipal de Lobos.

• evidência: issue #74 Nos ficheiros PDF não é possível, extrair o conteúdo textual para formato TXT

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 10.1

  Evidências

  Validado que alguns documentos não é possível exportar o conteúdo do PDF para formato TXT.

  

  URL:

  https://balcaomunicipal.cm-camaradelobos.pt/templates/viewer/js/pdfjsv2/web/viewer.html?file=https%3A%2F%2Fbalcaomunicipal.cm-camaradelobos.pt%2Fdocumentos%2Fdl%2F%3Frefid%3D83oz1vxylo08o8k4804w%26bname%3D6f37f152d3d7e15a93ffd667fe179254%26cname%3Da896e47f64232fe7132125d976b2bf55579dd709e7d04265b5e0c031c238cfb980dcf1e7b6c2d3188a3c83b5c41ec638ef6f65c29b2a6e19f477ed8696943a1d

  https://cm-camaradelobos.pt/informacoes/documentos/todos-os-documentos?QWdlbmRhIEN1bHR1cmFsIGRlIEPDom1hcmEgZGUgTG9ib3MmbGV2ZWwxPTQmbGV2ZWwyPTU5JmxldmVsMz0xOTM=

  https://cm-camaradelobos.pt/servicos/desporto/semana-do-desporto-de-camara-de-lobos

  Recomendações

  • Converter as imagens em tabelas para que seja possível exportar.
  • Converter os documentos para texto através do Reconhecimento Óptico de Caracteres (OCR) da Adobe.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #16 Falta de um resumo na página principal

  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 da câmara municipal de Câmara de Lobos, não aparece presente um resumo breve do próposito do site.

  

  Ecrã da página inicial sem dar scroll não inclui resumo a explicar o próposito do site

  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, 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:

  

  ImageExemplo de uma frase de propósito do website acessibilidade.gov

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #17 Falta de glossário para termos complexos

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.2

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

  Evidências:

  Ao longo do website, é possível identificar a utilização de diversos termos técnicos e complexos que surgem sem qualquer definição ou explicação associada. Na ausência de um glossário ou de mecanismos que permitam esclarecer esses conceitos, os utilizadores podem ter dificuldade em compreender plenamente a informação apresentada, especialmente aqueles que não estão familiarizados com a terminologia utilizada.

  Esta limitação compromete a acessibilidade e a clareza dos conteúdos, uma vez que obriga o utilizador a procurar significados fora do contexto do site ou a interpretar incorretamente a informação.

  

  Imagem com o termo complexo "CAE" sem definição agregada. Disponível em: Apoio às empresas - COVID -19

  

  Imagem com o termo complexo "BMCL" sem definição agregada. Disponível em: Biblioteca Municipal

  Outros exemplos:

  • IHRU: https://cm-camaradelobos.pt/servicos/urbanismo/programa-1-direito-plano-de-recuperacao-e-resiliencia-prr
  • MAD: https://cm-camaradelobos.pt/servicos/desporto/municipios-amigos-do-desporto
  • IFCN: https://cm-camaradelobos.pt/servicos/desporto/programa-andar-pela-saude
  • RAM: https://cm-camaradelobos.pt/servicos/social/plano-de-acao-para-a-coesao-social
  • PRCVD e RAM: https://cm-camaradelobos.pt/servicos/social/violencia-domestica

  Recomendações:

  Recomenda-se a criação de um glossário que permita a utilização consistente de siglas ao longo do website, evitando que o utilizador tenha de procurar repetidamente a sua definição noutros parágrafos.

  Como exemplo podem visualizar o glossario do acessibilidade.gov. https://www.acessibilidade.gov.pt/glossario/

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #18 Ausência de datas de atualização em certos conteúdos

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.3

  Cada bloco de conteúdo contém a sua data de atualização.
  – ver requisito 1.3 na lista Conteúdo

  Evidências:

  O website da Câmara Municipal de Câmara de Lobos apresenta, na maioria dos blocos de conteúdo, a data da última atualização. No entanto, verificam-se ainda alguns casos em que essa informação se encontra em falta.

  Exemplos NOK:

  • https://cm-camaradelobos.pt/informacoes/utilidades/multimedia
  • https://cm-camaradelobos.pt/informacoes/utilidades/multimedia
  • https://cm-camaradelobos.pt/informacoes/documentos/todos-os-documentos?MjAyMS0yMDI1JmxldmVsMj0xOCZsZXZlbDM9MTE2
  • https://cm-camaradelobos.pt/informacoes/documentos/todos-os-documentos?RWRpdGFpcyZsZXZlbDE9MSZsZXZlbDI9Mg==

  

  Imagem da página de multimédia sem data de atualização

  Recomendações:

  Recomenda-se a revisão integral do website, de modo a assegurar que a data de atualização esteja presente em todos os blocos de conteúdo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #35 O corpo de texto tem um tamanho inferior a 12pt (equivalente a 16px)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.1

  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 no menu principal, as opções de segundo nível estão com tamanho de letra abaixo do valor mínimo recomendado. (Figura 1)

  

  Figura 1 - Verificação do tamanho do texto nas opções de segundo nível do menu com apenas 15px

  Há botões de ação principal, com tamanho inferior ao recomendado. Por exemplo os botões “Digital”, “Mapa do site” e “Contactos na página inicial. (Figura 2)

  

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

  Existem formulários no website, por exemplo Opinião sobre os projetos municipais cujas labels associadas aos campos de preenchimento nomeadamente as checkboxs de declaração de conhecimento do utilizador com tamanho de letra de apenas 14px. (Figura 5)

  

  Figura 3- Textos com informações primárias dos campos de preenchimento dos formulários com dimensão inferior ao recomendado

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

  • Falar com o Presidente
  • Elogios, Reclamações, Informações e Dúvidas
  • Inscrições nas Reuniões de Câmara

  Recomendação de melhoria
  É necessário rever todo website, e corrigir os textos de informações primárias, para um tamanho igual ou superior ao recomendado.

• evidência: issue #34 O conteúdo do site fica desformatado em resoluções mais pequenas

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.1

  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

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

  O website apresenta inconsistências na variação dos tamanhos de letra em resoluções mais reduzidas. Por exemplo, na página Cultura nos Mercados voltou esta manhã ao Mercado do Estreito de Câmara de Lobos, verificou‑se que, ao alterar a resolução para um formato mobile, o corpo de texto do conteúdo fica desformatado e com uma dimensão inferior à recomendada, comprometendo a legibilidade. (Figura 1)

  

  Figura 1 - Corpo de texto com dimensão inferior ao recomendado

  

  Figura 2 - Verificação do texto na página Notícias com texto variável e tamanho de letra 15px inferior ao recomendado

  Recomendação

  As páginas devem ser revistas e adaptadas de modo a assegurar que o conteúdo se reorganiza corretamente e permanece totalmente utilizável em diferentes resoluções, tamanhos e orientações de ecrã, sem perda de informação ou funcionalidade.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #36 A informação secundária têm um tamanho de letra inferior a 10pt (equivalente a 13px)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.2

  A informação secundária (datas, autores) utiliza, no mínimo, um tamanho de letra de 10 pontos.
  – ver requisito 2.2 na lista Conteúdo

  Notas Gerais

  • Para garantir a legibilidade da informação secundária, esta deve ter um tamanho de letra igual ou superior a 13px (10pt).

  Durante a análise foram identificadas informações secundárias apresentadas com um tamanho de letra inferior ao mínimo recomendado. Por exemplo, na página Notícias de Câmara de Lobos, os textos do breadcrumb possuem valor de 11px, não cumprem o presente critério. (Figura 1)

  

  Figura 1 - Verificação do tamanho de letra do breadcrumb com valor inferior ao recomendado

  Esta dimensão reduzida compromete a legibilidade e cria barreiras para utilizadores com baixa visão ou que necessitem de ampliar o conteúdo.


  Outras páginas NOK:


  • Entrevista PEF | Vereadora da Educação, Sónia Brazão
  • Balcão do empreendedor
  • Teatro Metaphora leva Câmara de Lobos a rede europeia de participação juvenil

  Recomendação de melhoria

  Recomendamos revisar todo website, e aumentar o tamanho de letra das informações secundárias para, no mínimo 10 pontos(13px). Garantindo simultaneamente que a fonte permanece escalável, permitindo ampliação por tecnologias assistivas ou pelo zoom do navegador;

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #37 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).

  Verificámos que no website há blocos de textos apresentam largura superior ao recomendado por linha. Por exemplo na página Turismo Sénior - Porto Santo 2025 (Figura 1)

  

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

  Outras evidências (NOK)

  • https://cm-camaradelobos.pt/informacoes/utilidades/contactos
  • https://cm-camaradelobos.pt/servicos/ambiente/agenda-21
  • https://cm-camaradelobos.pt/servicos/social/cartao-municipal-senior-viva
  • https://cm-camaradelobos.pt/informacoes/utilidades/noticias-de-camara-de-lobos/detalhe/3542-cancelado-atuacao-de-roberto-jardim-no-mercado-do-estreito-de-camara-de-lobos
  • https://cm-camaradelobos.pt/servicos/protecao-civil/servico-municipal-de-protecao-civil

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

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.4

  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
  Na página inicial, há blocos de textos com espaçamento inferior ao recomendado, por exemplo na secção “Apoios Municipais” em que o espaçamento entre linhas é de 20px para um tamanho de letra de 20px. (Figura 1)



  

  Figura 1 - Textos com espaçamento inferior ao recomendado.

  Evidência 02
  Na página Urbanismo há blocos de textos com espaçamento apenas 20.4px para um tamanho de letra de 17px. (Figura 2)

  

  Figura 2 - O bloco de conteúdo das “Notícias Relacionadas” possui espaçamento inferior ao recomendado.

  As mesmas dimensões de espaçamento são aplicadas nos textos do menu principal, nas opções “Serviço” e “Participação”.
  E em outras páginas interiores, outros exemplos:

  • https://cm-camaradelobos.pt/informacoes/utilidades/noticias-de-camara-de-lobos
  • https://cm-camaradelobos.pt/institucional/camara-municipal/pelouros-municipais
  • https://cm-camaradelobos.pt/informacoes/documentos/todos-os-documentos?VklJIC0gUmVjdXJzb3MgSHVtYW5vcyZsZXZlbDE9Nw==

  Recomendação


  Para a evidência 01 apresentada, o espaçamento deveria ser, no mínimo 30px. Já para evidência 02 o espaçamento deveria ser, no mínimo 25.5px. É necessário rever todo website para garantir o espaçamento mínimo recomendado, relativo ao tamanho da letra.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #20 Excesso de opções no subnível do 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 navegação principal inclui um subnível com 14 opções disponíveis, ultrapassando o número recomendado para uma navegação clara e eficiente. Este excesso de escolhas pode dificultar a compreensão da estrutura do website, aumentar a carga cognitiva dos utilizadores e tornar a localização de conteúdos mais lenta e confusa.

  

  Imagem do subnível do menu principal com 14 opções.

  

  Imagem do menu do rodapé com 10 opções na secção de "Serviços Municipais"

  Outros casos NOK:

  • Serviços com 16 opções
  • Informações->Utilidades com 11 opções

  Também é solicitado que o menu secundário se mantenha equilibrado, respeitando igualmente o limite máximo de 9 opções. No entanto, existem os seguintes exemplos em que isso não se verifica:

  • Secção "Planos Relatórios e Estudos": https://cm-camaradelobos.pt/informacoes/documentos/todos-os-documentos?Q8OzZGlnbyBkZSBDb25kdXRhJmxldmVsMT00JmxldmVsMj0yNA==
  • Secção "Social": https://cm-camaradelobos.pt/servicos/social/cartao-municipal-senior-viva
  • Secção "Transparência Municipal": https://cm-camaradelobos.pt/institucional/transparencia-municipal/provedor-do-municipe

  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.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #21 Não é perceptível qual a posição atual do utilizador através do menu

  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

  Boas práticas:

  A opção do menu selecionada deve corresponder de forma consistente à página apresentada, garantindo que tanto o destaque visual no menu como as breadcrumbs refletem corretamente a localização atual do utilizador na arquitetura de informação.

  Problema específico:

  Ao clicar numa opção do menu, a página apresentada não corresponde à opção selecionada. Além disso, tanto o destaque no menu como as breadcrumbs indicam uma página diferente daquela que o utilizador escolheu, criando inconsistência na navegação e potencial confusão.

  

  Figura 01: Imagem da página redirencionada quando se segue o percurso Intitucional->Câmara Municipal->Código de Conduta no menu principal.

  Também é possível verificar que algumas páginas não apresentam qualquer indicação visual da posição do utilizador no menu lateral, ou são ativadas apenas com hover, enquanto outras o fazem. É importante garantir que esta indicação seja consistente em todo o site (Como exemplo ver Figura 02).

  Adicionalmente, todos os exemplos de NOK apresentados de seguida contêm breadcrumbs incorretos. Em vez de indicarem “Participação / Formulários Participação / Página atual”, apresentam apenas “Participação / Formulários Participação” (Ver Figura 03), o que compromete a correta identificação da localização da página.

  

  Figura 02: Imagem de exemplo ilustrando como o menu secundário deve apresentar a indicação visual da posição do utilizador.

  

  Figura 03: Imagem com os breadcrumbs incompletos da posição atual do utilizador.

  Exemplos NOK:

  • Falar com o Presidente
  • Opinião sobre os projetos municipais
  • Elogios, Reclamações, Informações e Dúvidas
  • Inscrições nas Reuniões de Câmara
  • Agenda 21

  Exemplos OK:

  • https://cm-camaradelobos.pt/servicos/social
  • https://cm-camaradelobos.pt/informacoes/utilidades/contactos
  • https://cm-camaradelobos.pt/informacoes/utilidades/informacoes-gerais

  Recomendação:

  Devem garantir que, ao selecionar uma opção do menu, o sistema direciona corretamente para a página correspondente e que tanto o menu como as breadcrumbs refletem essa mesma localização. A indicação da página atual deve ser consistente entre todos os elementos de navegação e, no caso do menu, deve incluir o atributo aria-current para assegurar acessibilidade às tecnologias de apoio.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #22 Hiperligações percetíveis apenas com hover

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.3

  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:

  Foram identificadas diversas hiperligações que dependem exclusivamente da cor para se distinguirem do restante conteúdo. Em muitos casos, o sublinhado apenas é exibido ao passar o cursor (hover), o que dificulta a identificação imediata de elementos clicáveis, especialmente para utilizadores com limitações visuais ou dificuldades de perceção de cor.

  Os links devem apresentar uma indicação visual adicional além da cor, visível de forma persistente, sem exigir interação do utilizador. A ausência dessa distinção pode comprometer a compreensão e a navegação no conteúdo.

  

  Imagem dos títulos das notícias sem qualquer indicação visual.

  

  Imagem de hiperligação com indicação visual apenas em hover na página de falar com o presidente.

  

  Imagem de hiperligações no header sem indicação visual.

  

  Imagem de hiperligações no rodapé com indicação visual apenas em hover

  Recomendações:

  • Garantir que todas as hiperligações possuem um indicador visual persistente, como sublinhado, independentemente de hover.
  • Evitar depender exclusivamente da cor para diferenciar links do texto normal.
  • Assegurar contraste adequado entre links e texto circundante, conforme os requisitos de acessibilidade.
  • Validar que estilos de foco (focus) também são visíveis e consistentes para navegação por teclado.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #24 Páginas extensas sem índice no topo com hiperligações internas para as secções

  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://cm-camaradelobos.pt/servicos/educacao/biblioteca-municipal

  A página apresenta uma extensão considerável, com múltiplos blocos de conteúdo, mas não disponibiliza um índice no topo com hiperligações internas para as diferentes secções. Esta ausência dificulta a navegação e o acesso rápido à informação.

  

  Outros exemplos:
  https://cm-camaradelobos.pt/servicos/educacao/plano-municipal-de-transporte-escolar
  https://cm-camaradelobos.pt/servicos/social/habitacao/estrategia-local-de-habitacao/plano-de-recuperacao-e-resiliencia-prr
  https://cm-camaradelobos.pt/servicos/social/plano-de-acao-para-a-coesao-social
  https://cm-camaradelobos.pt/servicos/ambiente/agenda-21
  https://cm-camaradelobos.pt/servicos/protecao-civil/servico-municipal-de-protecao-civil

  Recomendação
  Adicionar um índice no topo da página com hiperligações internas para as principais secções de conteúdo, refletindo a hierarquia de cabeçalhos e facilitando a navegação em páginas extensas.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #25 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://cm-camaradelobos.pt/participacao/formulario?ref=bDZ1NHRqYXo=

  Em dispositivos móveis, os botões de seleção (radio buttons) apresentam desalinhamento em relação ao respetivo texto, devido à quebra inadequada de layout. Esta situação dificulta a leitura e a associação entre as opções e os seus rótulos.

  

  Figura 01 – Botões radio desalinhados em dispositivos móveis, dificultando a leitura e associação com o rótulo.

  Outro exemplo:
  https://cm-camaradelobos.pt/participacao/formulario?ref=aGJ3YWczenA=

  Recomendação
  Ajustar o layout dos elementos de formulário em dispositivos móveis, garantindo o alinhamento consistente entre os botões de seleção e os respetivos rótulos, evitando quebras de linha que prejudiquem a legibilidade e a interação.

  Ponto 02
  Página: https://cm-camaradelobos.pt/participacao/formulario?ref=bDZ1NHRqYXo=

  Na versão móvel da página, especificamente em dispositivos como o iPhone 14, os elementos gráficos apresentados no rodapé não se adaptam corretamente à largura do ecrã. As imagens/logótipos mantêm dimensões e posicionamento fixos, ficando excessivamente próximas das margens laterais e comprometendo a apresentação visual do conteúdo.

  

  Figura 02 – Elementos gráficos no rodapé sem adaptação adequada ao ecrã em dispositivos móveis.

  Recomendação
  Garantir que os elementos gráficos do rodapé se adaptam corretamente a diferentes larguras de ecrã, aplicando comportamento responsivo adequado, com redimensionamento proporcional e margens laterais consistentes, assegurando uma apresentação equilibrada em dispositivos móveis.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #26 Conteúdo e elementos interativos acessíveis apenas por hover

  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://cm-camaradelobos.pt/

  Os itens da galeria apresentam informação adicional (legenda) apenas através de interação por hover (passagem do rato). Esta informação não é disponibilizada através de navegação por teclado (ex.: tecla Tab), nem está acessível em dispositivos com interação por toque, comprometendo o acesso ao conteúdo para utilizadores que não utilizam rato.

  

  Figura 01 – Legenda da galeria visível apenas em hover.

  

  Figura 02 – Legenda da galeria inacessível em dispositivos móveis por depender exclusivamente de hover.

  Recomendação
  Garantir que a informação apresentada por hover esteja igualmente disponível através de foco por teclado e interação por toque, ou de forma persistente.

  Ponto 02
  Página: https://cm-camaradelobos.pt/servicos/social/apoio-as-pessoas-em-situacao-de-sem-abrigo

  Foi identificado um elemento interativo no rodapé do conteúdo que apenas se torna visível quando o utilizador passa o rato sobre a área correspondente. Este comportamento impede o acesso à funcionalidade em dispositivos sem interação por hover, como dispositivos móveis ou navegação por teclado.

  

  Figura 03 – Elemento interativo visível apenas em hover, não acessível por teclado ou dispositivos touch.

  Recomendação
  Garantir que todos os elementos interativos estão sempre visíveis ou acessíveis sem necessidade de interação por hover, assegurando a sua utilização em dispositivos táteis e por navegação via teclado.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #4 Elementos interativos com área clicável inferior ao mínimo recomendado (44×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://cm-camaradelobos.pt/

  O botão de pesquisa, os ícones de redes sociais e o seletor de idioma apresentam dimensões inferiores ao mínimo recomendado de 44×44px para elementos interativos.

  Há páginas interiores que apresentam os ícones das redes sociais “Facebook”, “WhatsApp”, “Twitter” e “Email” com dimensões de 30×33px, igualmente inferiores ao mínimo recomendado.

  Estas dimensões reduzidas podem dificultar a interação, especialmente em dispositivos móveis ou para utilizadores com limitações motoras.

  

  Figura 01 – Botão de pesquisa com dimensão inferior ao mínimo recomendado para elementos interativos.

  

  Figura 02 – Ícones de redes sociais com área interativa inferior ao mínimo recomendado, dificultando a utilização em dispositivos móveis e por utilizadores com limitações motoras.

  Exemplos de páginas qe apresentam icones com dimensões inferiores:
  https://cm-camaradelobos.pt/informacoes/utilidades/multimedia
  https://www.cm-camaradelobos.pt/servicos/ambiente
  https://www.cm-camaradelobos.pt/participacao/formulario?ref=bTZiMm5ud3c=

  Recomendação
  Aumentar a área interativa do botão de pesquisa, dos ícones de redes sociais e do seletor de idioma para, no mínimo, 44×44px, garantindo uma interação mais confortável e acessível.

  Ponto 02
  Página: https://cm-camaradelobos.pt/

  O botão de “voltar ao topo” apresenta dimensões inferiores ao mínimo recomendado de 44×44px, podendo dificultar a interação, especialmente em dispositivos móveis ou para utilizadores com limitações motoras.

  

  Figura 03 – Botão “voltar ao topo” com dimensão inferior ao mínimo recomendado.

  Recomendação
  Aumentar a área clicável do botão para, no mínimo, 44×44px, garantindo uma interação mais acessível e confortável, sem necessidade de alterar significativamente o design visual.

  Ponto 03
  Página: https://cm-camaradelobos.pt/

  O botão de ação presente no banner apresenta dimensões de 40×20px, inferiores ao mínimo recomendado de 44×44px para elementos interativos. Esta dimensão reduzida pode dificultar a interação, especialmente em dispositivos móveis ou para utilizadores com limitações motoras.

  

  Figura 04 – Botão de ação no banner com dimensão inferior ao mínimo recomendado.

  Recomendação
  Aumentar a área clicável do botão para, no mínimo, 44×44px, garantindo uma zona de interação adequada.

  Ponto 04
  Página: https://cm-camaradelobos.pt/

  Os seletores do carrossel no banner inicial apresentam dimensões de 15×15px, inferiores ao mínimo recomendado de 44×44px para elementos interativos. Esta dimensão reduzida pode dificultar a sua utilização, especialmente em dispositivos móveis ou por utilizadores com limitações motoras.

  

  Figura 05 – Seletores do carrossel com dimensão inferior ao mínimo recomendado.

  Recomendação
  Aumentar a área clicável dos seletores do carrossel para, no mínimo, 44×44px.

  Ponto 05
  Página: https://cm-camaradelobos.pt/participacao/formulario?ref=bTZiMm5ud3c=

  Os elementos de seleção (checkbox) apresentam uma área clicável com altura inferior ao mínimo recomendado de 44px, apesar de estarem corretamente associados ao respetivo label. Esta dimensão reduzida pode dificultar a interação.

  

  Figura 06 – Checkbox com área clicável inferior ao mínimo recomendado.

  Outros exemplos:
  https://cm-camaradelobos.pt/participacao/formulario?ref=bDZ1NHRqYXo=
  https://cm-camaradelobos.pt/participacao/formulario?ref=aGJ3YWczenA=
  https://cm-camaradelobos.pt/participacao/formulario?ref=cTBuZ2NveTI=

  Recomendação
  Aumentar a área clicável vertical dos elementos de seleção para, no mínimo, 44px, garantindo uma interação mais confortável, por exemplo através do aumento de padding ou espaçamento do elemento "label".

  Ponto 06
  Página: https://cm-camaradelobos.pt/participacao/formulario?ref=bDZ1NHRqYXo=

  Os botões de seleção (radio buttons) apresentam uma área clicável inferior ao mínimo recomendado de 44×44px, com dimensões visuais reduzidas.

  

  Figura 07 – Botões radio com área clicável inferior ao mínimo recomendado.

  Outros exemplos
  https://cm-camaradelobos.pt/participacao/formulario?ref=aGJ3YWczenA=
  https://cm-camaradelobos.pt/participacao/formulario?ref=cTBuZ2NveTI=

  Recomendação
  Aumentar a área clicável dos botões de seleção para, no mínimo, 44×44px

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #28 Ausência de hierarquia visual clara entre ações principais e secundárias

  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://cm-camaradelobos.pt/informacoes/documentos/todos-os-documentos?Qm9sZXRpbSBNdW5pY2lwYWwmbGV2ZWwxPTgmbGV2ZWwyPTQ1

  O botão de “voltar ao topo” apresenta o mesmo estilo visual do botão de ação principal em algumas páginas, não existindo uma diferenciação clara entre ambos. Esta semelhança pode gerar confusão na hierarquia de ações, dificultando a identificação do botão principal por parte dos utilizadores.

  

  Outros exemplos:
  https://cm-camaradelobos.pt/informacoes/documentos/todos-os-documentos?RGlyZWl0byBkZSBPcG9zacOnw6NvJmxldmVsMT04JmxldmVsMj0yMA==
  https://cm-camaradelobos.pt/informacoes/documentos/todos-os-documentos?MDYgLSBVcmJhbmlzbW8mbGV2ZWwxPTY=
  https://cm-camaradelobos.pt/informacoes/documentos/todos-os-documentos?Q29uc3VsdGEgUMO6YmxpY2EmbGV2ZWwxPTgmbGV2ZWwyPTU2
  https://cm-camaradelobos.pt/informacoes/documentos/todos-os-documentos?VGF4YXMsIFByZcOnb3MgZSBMaWNlbsOnYXMgTXVuaWNpcGFpcyZsZXZlbDE9NSZsZXZlbDI9MTYmbGV2ZWwzPTM2

  Recomendação
  Diferenciar visualmente o botão de “voltar ao topo” do botão de ação principal, recorrendo a estilos distintos (ex.: cor, preenchimento, contorno ou destaque visual), de forma a reforçar a hierarquia e facilitar a identificação da ação principal.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #30 Elementos interativos sem indicação visual clara 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://cm-camaradelobos.pt/

  Os itens da galeria apresentam problemas de perceção visual. Os ícones de identificação de conteúdo (imagem ou vídeo) possuem baixo contraste em relação ao fundo, dificultando a sua identificação em determinadas situações.
  Adicionalmente, os elementos clicáveis da galeria não apresentam indicadores visuais claros de interatividade, podendo ser percecionados como conteúdos estáticos.

  

  Figura 01 – Ícones com baixo contraste face ao fundo, dificultando a identificação do tipo de conteúdo.

  Ponto 02
  Página: https://cm-camaradelobos.pt/

  O botão de ação no banner apresenta um contraste insuficiente no estado hover, com um rácio de 1.57:1, abaixo do mínimo recomendado de 3:1 para elementos gráficos interativos. Esta situação dificulta a perceção da mudança de estado.

  

  Figura 02 – Botão com contraste insuficiente no estado hover, dificultando a perceção da interação.

  Recomendação
  Aumentar o contraste entre o botão e o fundo no estado hover, garantindo um rácio mínimo de 3:1, de forma a tornar a mudança de estado claramente perceptível para todos os utilizadores.

  Ponto 03
  Página: https://cm-camaradelobos.pt/participacao/formulario?ref=bTZiMm5ud3c=

  A sidebar de navegação lateral não evidencia de forma clara que os seus elementos são interativos, podendo ser percecionada como conteúdo estático. A ausência de indicadores visuais de clique dificulta a identificação das opções de navegação como elementos clicáveis.

  A sidebar de navegação lateral não evidencia de forma clara que os seus elementos são interativos, podendo ser percecionada como conteúdo estático. A ausência de indicadores visuais de clique dificulta a identificação das opções de navegação como elementos clicáveis.

  Esta inconsistência visual também impacta na perceção da posição do utilizador nas páginas "(ver o Requisito 3.2)"

  

  Figura 03 – Card sem indicação visual clara de interatividade.

  Outros exemplos:
  https://www.cm-camaradelobos.pt/participacao/formulario?ref=bDZ1NHRqYXo=
  https://www.cm-camaradelobos.pt/participacao/formulario?ref=aGJ3YWczenA=
  https://www.cm-camaradelobos.pt/participacao/formulario?ref=cTBuZ2NveTI=
  https://cm-camaradelobos.pt/servicos/ambiente

  Foram identificadas páginas onde a navegação lateral apresenta indicadores visuais de interatividade mais claros e consistentes. A diferença de comportamento visual entre sidebars compromete a consistência da navegação e a perceção da posição do utilizador no sítio Web.

  Exemplos claros encontrados
  https://cm-camaradelobos.pt/informacoes/utilidades/informacoes-gerais
  https://cm-camaradelobos.pt/informacoes/utilidades/contactos
  https://cm-camaradelobos.pt/servicos/social

  Recomendação
  Reforçar a perceção de interatividade através de indicadores visuais claros, como diferenciação visual dos itens ou outros elementos que sinalizem a possibilidade de clique.

  Ponto 04
  Página: https://cm-camaradelobos.pt/

  Na página inicial, ao aceder ao menu “Institucional”, é apresentado um submenu onde a imagem e o nome do Presidente possuem comportamento interativo, mas não apresentam indicadores visuais claros de que são clicáveis, sendo percecionados como conteúdo estático.

  

  Figura 04 – Elementos interativos no submenu “Institucional” sem indicação visual clara de interatividade.

  Recomendação
  Reforçar a perceção de interatividade da imagem e do nome do Presidente através de indicadores visuais claros, como estados de hover e foco, alteração de estilo (ex.: sublinhado, mudança de cor ou cursor pointer) ou outros elementos que sinalizem a possibilidade de clique.

• evidência: issue #29 Falta de perceção de interatividade em imagens que acionam modais

  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://cm-camaradelobos.pt/servicos/social/apoio-as-pessoas-em-situacao-de-sem-abrigo

  A imagem apresentada na página funciona como elemento interativo, permitindo o acesso ao mesmo destino do botão “Consultar o Plano”. No entanto, não apresenta qualquer indicador visual de interatividade, sendo percecionada como conteúdo meramente decorativo ou informativo.

  

  Figura 01– Imagem clicável sem indicação visual de interatividade.

  Outros exemplos:
  https://cm-camaradelobos.pt/servicos/social/violencia-domestica
  https://cm-camaradelobos.pt/servicos/ambiente/pacto-de-autarcas
  https://cm-camaradelobos.pt/servicos/urbanismo/oru-operacao-de-reabilitacao-urbana
  https://cm-camaradelobos.pt/servicos/social/habitacao

  Recomendação
  Garantir que a imagem interativa apresenta indícios claros de clicabilidade, como cursor pointer, efeito visual ao hover/focus, ícone indicativo ou estilo visual semelhante a um botão, assegurando que os utilizadores percebem que pode ser acionada.

  Ponto 02
  Página: https://cm-camaradelobos.pt/servicos/social/tome-iniciativa-mexa-se-mais

  Apesar da indicação textual “clique abaixo”, os elementos gráficos apresentados não possuem características visuais que indiquem interatividade, sendo percecionados como conteúdo meramente informativo. A dependência exclusiva de instrução textual não garante que todos os utilizadores identifiquem corretamente os elementos como clicáveis.

  

  Figura 02 – Elementos gráficos sem indicação visual de interatividade apesar da instrução “clique abaixo”.

  Recomendação
  Garantir que os elementos gráficos interativos apresentam indícios visuais claros de clicabilidade, como estilos de botão, ícones indicativos, efeitos de hover/focus ou outros elementos visuais que reforcem a sua natureza interativa, não dependendo exclusivamente de instruções textuais.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #10 Não foram encontrados formulários com mais de 2 ecrãs no website

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

  Evidências

  Não foram encontrados formulários com mais de dois ecrãs no site Portal Municipal de Câmara de Lobos. Assim, este critério é considerado "Não aplicável (N/A)".

  Recomendações

  No response

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #13 Não foram encontrados formulários com mais de uma página

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

  Evidências

  Não foram encontrados formulários com mais de uma página dentro do Portal Municipal de Câmara de Lobos. Assim, este requisito fica avaliado como "Não Aplicável".

  Recomendações

  No response

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #14 O tamanho do campo não reflete o tamanho previsível dos dados

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

  Evidências

  Verificámos que no campo “Assunto” do formulário da página Falar com o Presidente, o campo é demasiado largo para o tipo de informação a inserir. Isto pode confundir utilizadores, pois o tamanho do campo sugere que devem escrever mais texto do que o adequado.

  Recomendamos ajustar a largura dos campos do formulário para que corresponda ao conteúdo esperado.

  

  Figura - Formulário da página Falar com o Presidente. Campo "Assunto" está destacado através de um retângulo de borda preta.

  Recomendações

  No response

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #15 Não foram identificados formulários que utilizem revelação progressiva

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

  Evidências

  No Portal Municipal de Câmara de Lobos, não foram encontrados campos cujo conteúdo dependente seja ocultado ou revelado automaticamente com base na ativação de um campo chave. Assim, o requisito 2.2. da Checklist de Transação é avaliado como “Não aplicável”.

  Recomendações

  No response

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #60 Caixas de combinação não estão estruturadas de forma acessível

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

  Evidências

  Verificámos que, nas comboboxes presentes nas páginas Notícias de Câmara de Lobos, Multimédia e Reels, o leitor de ecrã não consegue aceder aos rótulos dos campos — quando o utilizador navega com Tab ou Shift+Tab — nem às opções disponíveis dentro de cada combobox. Quando o utilizador tenta navegar pelas opções, o leitor de ecrã anuncia apenas “Em branco”, em vez de ler cada opção disponível.

  Isto significa que estas caixas de combinação não estão estruturadas de forma acessível.

  

  Figura 1 - Análise da página Notícias de Câmara de Lobos através de Tab e Shift+Tab e do leitor de ecrã NVDA. Os rótulos dos campos "Categoria" e "Ano" não estão a ser anunciados pelo leitor de ecrã.

  

  Figura 2 - Análise da página Multimédia através de Tab e Shift+Tab e do leitor de ecrã NVDA. Os rótulos dos campos "Filtrar por Categoria" e "Filtrar por Ano" não estão a ser anunciados pelo leitor de ecrã.

  

  Figura 3 - Análise do campo "Filtrar por Categoria" da página Multimédia através do leitor de ecrã NVDA. Quando o utilizador tenta navegar pelas opções da combobox, o leitor de ecrã anuncia apenas “Em branco”, em vez de ler cada opção disponível.

  

  Figura 4 - Análise do campo "Filtrar por Categoria", da página Multimédia, através do Google Inspector.

  Recomendações

  Sugerimos que estes componentes sejam reestruturados para garantir total compatibilidade com tecnologias de apoio.

  Como referência para uma implementação acessível de uma combobox, recomendamos consultar o exemplo da W3C Editable Combobox With Both List and Inline Autocomplete.

  Se concluírem que o número de opções não justifica o uso de uma combobox, podem optar por alternativas mais simples, como listas suspensas ou radio buttons. A página Creating Accessible Forms apresenta exemplos práticos de implementações acessíveis destes componentes.

• evidência: issue #59 A legenda do campo de pesquisa não é anunciada pelo leitor de ecrã nem aparece na interface

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

  Evidências

  Verificámos que no campo de pesquisa da página Pesquisar | Motor de busca, existe um elemento <label> dentro da estrutura do formulário, mas este não está a ser reconhecido pelo leitor de ecrã nem está visível na interface gráfica.

  

  Figura - Análise do campo de pesquisa da página Pesquisar | Motor de busca através do Google Inspector.

  Recomendações

  Recomendamos que este campo seja reestruturado. Deve ser utilizado um elemento <label> para apresentar a legenda do campo (por exemplo, “Pesquisar:”), que deve ficar acessível para tecnologias de apoio e visível na interface gráfica, e um elemento <input> para o campo onde o utilizador escreve o termo de pesquisa.

  Como referência para uma implementação acessível, podem consultar o conteúdo dentro do cabeçalho “Text Inputs”, da página Creating Accessible Forms da WebAIM, onde é apresentado um exemplo claro de como estruturar corretamente este tipo de campo.

etiqueta: NOK

Lista de evidências recolhidas:

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

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

  Evidências

  Verificámos que, em alguns campos dos formulários do Portal Municipal de Câmara de Lobos, existem campos de preenchimento obrigatório que não estão programaticamente definidos como tal.

  

  Figura 1 - Análise do campo "Declaro sob compromisso de honra a veracidade do reporte submetido e assumo toda a responsabilidade consequente de falsas declarações ou inexatidão", da página Falar com o Presidente, através do Google Inspector.

  

  Figura 2 - Análise do campo "Declaro ter conhecimento da política de privacidade da Câmara Municipal de Câmara de Lobos.", da página Opinião sobre os Projetos Municipais, através do Google Inspector.

  Recomendações

  Recomendamos que, em todos os campos obrigatórios, seja 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:

  Falar com o Presidente
  Campos:

  • Descrição do Assunto
  • Declaro sob compromisso de honra a veracidade do reporte submetido e assumo toda a responsabilidade consequente de falsas declarações ou inexatidão
  • Declaro ter conhecimento da política de privacidade da Câmara Municipal de Câmara de Lobos.

  Opinião sobre os Projetos Municipais
  Campos:

  • Descrição da opinião
  • Declaro sob compromisso de honra a veracidade do reporte submetido e assumo toda a responsabilidade consequente de falsas declarações ou inexatidão
  • Declaro ter conhecimento da política de privacidade da Câmara Municipal de Câmara de Lobos.

  Elogios, Reclamações, Informações e Dúvidas
  Campos:

  • Descrição
  • Declaro sob compromisso de honra a veracidade do reporte submetido e assumo toda a responsabilidade consequente de falsas declarações ou inexatidão
  • Declaro ter conhecimento da política de privacidade da Câmara Municipal de Câmara de Lobos.

  Inscrições nas Reuniões de Câmara
  Campos:

  • Declaro sob compromisso de honra a veracidade do reporte submetido e assumo toda a responsabilidade consequente de falsas declarações ou inexatidão
  • Declaro ter conhecimento da política de privacidade da Câmara Municipal de Câmara de Lobos.

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

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

  Evidências

  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 nos formulários das páginas Falar com o Presidente, Opinião sobre os Projetos Municipais, Elogios, Reclamações, Informações e Dúvidas e Inscrições nas Reuniões de Câmara não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

  

  Figura 1 - Formulário da página Falar com o Presidente. Não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

  

  Figura 2 - Formulário da página Inscrições nas Reuniões de Câmara. Não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

  Recomendações

  Recomendamos a revisão dos formulários de forma a ser adicionada uma legenda no início do formulário a indicar claramente o significado de *.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #3 Inexistência de ações longas

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

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

  Na análise realizada, não foram identificadas ações longas que exijam comunicação de estado ao utilizador.

  Desta forma, considera-se que o critério é não aplicável.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #2 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), 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.

  URL a verificar

  • https://am.cm-camaradelobos.pt/participacao/inscricao-na-sessao-da-assembleia

  Evidências:

  Após submissão do formulário:

  • 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 1 – 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
  • Validar com leitores de ecrã e navegação por teclado

etiqueta: N/A

Lista de evidências recolhidas:

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

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

  Evidências

  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".

  Recomendações

  No response

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #73 Existem mensagens não associadas programaticamente aos campos

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

  Evidências

  Existem checkboxes que não têm as mensagens programaticamente associadas:

  

  checkbox no formulário OPINIÃO SOBRE OS PROJETOS MUNICIPAIS que não tem a mensagem de erro programaticamente associada

  Recomendações

  Recomendamos que todos os campos tenham as mensagens de erro programaticamente associada, para que sejam lidas pelos leitores de ecrã quando se navega por teclado.

• evidência: issue #72 Existem mensagens de erro apresentadas entre a etiqueta e o campo

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

  Evidências

  Os formulários que precisam de apresentar mensagens de erro apresentam-nas junto aos campos. No entanto, existem campos cujas mensagens de erro associadas são apresentadas a seguir às labels em vez de serem as últimas componentes a serem apresentadas. Referimo-nos concretamente às textareas personalizadas do formulário presente na página OPINIÃO SOBRE OS PROJETOS MUNICIPAIS:

  

  Mensagem de erro apresentada a seguir à etiqueta

  Recomendações

  Recomendamos que as mensagens de erro sejam as últimas componentes dos campos a serem apresentadas, para manutenção da coerência com todos os outros controlos de formulários existentes no site. No caso tas textareas, deve ser anunciada etiqueta, em seguida o controlo (textarea) e finalmente a mensagem de erro.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #75 Existem mensagens de erro que não ajudam na resolução do problema

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

  Evidências

  A mensagem de erro “Por favor, introduza um endereço eletrónico válido” presente no formulário OPINIÃO SOBRE OS PROJETOS MUNICIPAIS não ajuda no preenchimento do campo:

  

  _ Mensagem de erro no topo da página que não guia o utilizador na resolução do erro_
  Como observado na figura, a mensagem “Por favor, introduza um endereço eletrónico válido” que é apresentada quando o campo foi preenchido com um formato incorreto não indica qual o formato a ser inserido, não ajudando a preencher o campo.

  Recomendações

  Recomendamos rever todos os formulários do website para garantir que as mensagens de erro apresentadas expliquem para o utilizador como preencher os campos corretamente.

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

Lista de evidências recolhidas:

• evidência: issue #50 Outras violações -Foco não está visível na navegação por teclado e leitor de ecrã

  etiqueta: melhoriaetiqueta: outras violações

  Evidências

  Descrição da problemática
  Ao navegar pelo website utilizando apenas o teclado, nem sempre o indicador de foco se encontra visível, dificultando significativamente a navegação, em particular para utilizadores que dependem exclusivamente deste meio de interação.

  Durante a navegação sequencial através da tecla TAB, há algumas componentes que não são circuscritas pelo foco por exemplo durante a navegação por teclado nos cards das “Notícias e Destaques”, “Agenda” e “Serviços Municipais para os cidadãos”. (Figura 1, 2 e 3)

  

  Figura 1 – Exemplo de ausência de foco visível na navegação por teclado

  

  Figura 2 – Exemplo de foco visível mas não circunscreve corretamente a componente

  

  Figura 3 - Exemplo de foco escondido por trás dos cards

  Em alguns momentos o foco não é apresentado de forma perceptível, sendo apenas possível inferir a sua existência através da barra de estado do navegador, o que não constitui uma solução acessível nem adequada. Sendo assim não é possível identificar visualmente a posição do utilizador em cada momento da navegação. Esta situação pode levar o utilizador a perder a noção da sua posição na página, comprometendo a usabilidade e a acessibilidade do website.

  Recomendações

  Garantir que todos os elementos interativos do website apresentam um indicador de foco visível, suficientemente contrastante e consistente, sempre que recebem foco através da navegação por teclado.
  O estilo de foco deverá:

  • Ser claramente percetível visualmente (ex.: contorno, sublinhado ou mudança de cor);
  • Manter contraste adequado em relação ao fundo;
  • Não ser removido através de regras CSS como outline: none sem alternativa equivalente;
  • Acompanhar corretamente a ordem lógica da navegação por teclado.

  Esta melhoria é essencial para assegurar uma navegação acessível a utilizadores com deficiência visual, motora ou cognitiva

• evidência: issue #49 Outras violações - Botão sem nome acessível

  etiqueta: melhoriaetiqueta: outras violações

  Evidências

  Descrição da problemática
  Na página Municípios Amigos do Desporto verifica‑se a existência de um botão/link sem nome acessível e não percetível, representado apenas pelo ícone “+”, que direciona para a página de Facebook da entidade. Este elemento não possui um rótulo textual ou nome acessível que permita identificar claramente o seu objetivo.
  (Figura 1)

  

  Figura 1 - Botão sem nome acessível e não percetível visualmente apenas com o símbolo “+”

  Durante a navegação com leitor de ecrã (NVDA), o elemento é anunciado apenas como “+ visitado link”, não fornecendo qualquer informação sobre a sua função ou destino. Esta situação impede que utilizadores de tecnologias de apoio compreendam que o link conduz para Página do Facebook, comprometendo a perceção, a usabilidade e a autonomia na navegação.

  Recomendações

  Recomendação de melhoria
  Deve ser atribuído um nome acessível e descritivo ao botão/link que direciona para o Facebook, através de texto visível por exemplo “Ler mais no Facebook” ou de um rótulo programático (por exemplo, aria-label). O elemento deve permitir que os leitores de ecrã anunciem claramente o seu propósito, garantindo que todos os utilizadores compreendem o destino da ligação e conseguem navegar de forma autónoma e informada.

• evidência: issue #48 Outras Violações - Uso inadequado de overlays de acessibilidade

  etiqueta: melhoriaetiqueta: outras violações

  Evidências

  Descrição da problemática

  • Os overlays de acessibilidade são frequentemente utilizados como soluções rápidas, mas não corrigem os problemas reais do website. Estas ferramentas funcionam como camadas sobrepostas ao código existente, sem resolver falhas estruturais como erros de semântica, foco, landmarks ou navegação por teclado.

  Em todo website, é disponibilizado uma “ferramenta de acessibilidade” que em alguns casos, podem interferir com tecnologias de apoio (ex.: NVDA), criando comportamentos inesperados, atalhos redundantes ou problemas de apresentação, como textos muito pequenos que afetam a legibilidade e problemas de contraste (Figura 1 e 2).

  

  Figura 1 - Textos muito pequenos com ferramenta overlays de acessibilidade

  

  Figura 2 - Problemas de contraste com ferramenta overlays de acessibilidade

  Além disso, transmitem uma falsa perceção de conformidade, mantendo problemas de acessibilidade para utilizadores reais.

  Recomendações

  Recomendação de melhoria
  Recomenda‑se que a acessibilidade seja assegurada prioritariamente através de boas práticas nativas: uso correto de HTML semântico, navegação por teclado funcional, contraste adequado e compatibilidade com tecnologias de apoio. Os overlays não devem substituir a correção estrutural do site, pois a melhoria da acessibilidade deve começar na base do código e não depender exclusivamente de ferramentas externas. Sendo assim, devem ser removidos do website.

• evidência: issue #47 Outras violações - Link “Ir para conteúdo” não é visível

  etiqueta: melhoriaetiqueta: outras violações

  Evidências

  Descrição da problemática
  Na estrutura do website encontra‑se disponível o link “Ir para conteúdo”, cuja finalidade é permitir aos utilizadores contornar blocos repetitivos de navegação e aceder diretamente à área principal do conteúdo.
  No entanto, este link não é apresentado de forma visível, não sendo identificado como um botão ou link interativo durante a navegação visual. Adicionalmente, não é devidamente percetível, comprometendo a sua função para utilizadores que navegam exclusivamente por teclado.

  

  Figura 1 - Inexistência operacional do link “ir para conteudo” do ponto de vista do utilizador com leitor de ecrã NVDA

  

  Figura 2 – Inspeção do link “Ir para conteúdo” que não está visível

  Esta situação impede que o mecanismo de salto cumpra o seu propósito de facilitar a navegação eficiente e inclusiva, reduzindo a usabilidade global do website e criando barreiras de acesso à informação.

  Recomendações

  Assegurar que o link “Ir para conteúdo” seja:

  • Visualmente percetível, apresentando-se como um elemento interativo (link ou botão);
  • Disponível e visível quando recebe foco por teclado;
  • Corretamente identificado e anunciado por leitores de ecrã;
  • Posicionado de forma lógica no início da página, antes dos blocos de navegação repetitivos.

  O link deverá tornar‑se visível aquando da navegação por teclado (por exemplo, ao receber foco através da tecla TAB) e permitir que todos os utilizadores compreendam claramente a sua função.