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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #47 R 1.1 - 10 Aspetos Web (Menu, lista de opções)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.1

  Evidências

  As opções do rodapé não estão estruturadas como uma lista
  No rodapé as opções estão sendo agrupadas por div genéricas:

  
  

  URL

  • https://agenda.cm-camaradelobos.pt/ - Opções do rodapé

  Recomendações

  • Devem estruturar as opções dentro de uma lista não ordenada ul li.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #66 R 1.2 - 10 Aspetos Web (Menu, navegação rato e teclado)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

  Evidências

  O menu principal está construído de forma inapropriada
  Quando se navega com o leitor de ecrã no menu mobile, as opções são anunciadas como se estivessem dentro de um painel de tabulação. Isto ocorre porque as opções estão estruturadas como um componente de tab.

  Existem problemas nessa construção, os elementos atribuídos como tablist encontram‑se ocultos no menu mobile. Como resultado, os leitores de ecrã interagem apenas parcialmente com o componente de tabulação, o que provoca inconsistências e dificuldades de navegação.

  

  Componente tabulador tablist visível para o menu desktop

  

  Componente tabulador com as opções tablist ocultas

  URL

  • https://agenda.cm-camaradelobos.pt/ - menu principal

  Recomendações

  • Remover a estrutura de tabulador para garantir que a navegação pelo menu seja assertiva: role="tablist", role="tabpanel" e role="tab".
  • As opções do menu devem estar estruturadas apenas como lista ul ``li.

• evidência: issue #64 R 1.2 - 10 Aspetos Web (Menu, navegação rato e teclado)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

  Evidências

  O menu principal não está estruturado como uma navegação
  Verifica-se que não está a ser utilizado a tag nav no menu. 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://agenda.cm-camaradelobos.pt/ - menu principal

  Recomendações

  • Verificar o menu mobile e desktop.
  • O menu deve ser estruturado dentro de uma tag nav.

• evidência: issue #63 R 1.2 - 10 Aspetos Web (Menu, navegação rato e teclado)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

  Evidências

  Não é possível identificar quando o menu está aberto ou fechado com o leitor de ecrã
  A abertura e fecho do menu não está a ser informada para os leitores de ecrã. Isso acontece porque não está a ser utilizado o atributo aria-expanded:

  

  URL

  • https://agenda.cm-camaradelobos.pt/ - menu principal

  Recomendações

  • Utilizar o atributo aria-expanded em conjunto com um script no código para gerenciar a abertura/fecho das opções e notificar as tecnologias de apoio.

• evidência: issue #57 R 1.2 - 10 Aspetos Web (Menu, navegação rato e teclado)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.2

  Evidências

  O foco do leitor de ecrã é direcionado automaticamente para a opção "Submeter evento"
  Quando abrimos o menu com o leitor de ecrã, o foco é automaticamente colocado na opção “Submeter evento”, que é uma das últimas opções do menu:

  
  

  URL

  • https://agenda.cm-camaradelobos.pt/ - menu principal

  Recomendações

  • O foco do leitor de ecrã deve respeitar a ordem de navegação natural: da esquerda para a direita, de cima para baixo, ou seja, quando o menu for aberto, o foco do leitor de ecrã deverá ser posicionado na primeira opção do menu. Essa alteração deve ser feita no menu desktop.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #65 R 1.3 - 10 Aspetos Web (Menu, imagens-link)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.3

  Evidências

  As imagens do menu principal possuem texto alternativo incorreto
  O botão de abrir e fechar o menu estão com o mesmo texto alternativo "Menu | Agenda Câmara de Lobos". Para além disso o nome acessível está a ser transmitido pelo atributo title:

  

  Recomendações

  • O atributo title deve ser utilizado apenas quando existir informação complementar. No caso do menu, o nome acessível é uma informação primária que deve ser transmitida corretamente às tecnologias de apoio. Por esse motivo, o title deve ser removido.
  • O nome acessível do botão pode ser fornecido através de um texto visível dentro do próprio botão. Esse texto deve estar presente para que, além do ícone, exista uma indicação visual clara de que se trata de um botão de menu. Por exemplo:

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #72 R 2.1 - 10 Aspetos Web (Títulos, nível 1)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 2.1

  Evidências

  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.

  Actualmente, todas as páginas apresentam o mesmo <h1> ("Agenda 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 .

  URLs a verificar:
  https://agenda.cm-camaradelobos.pt/ (rever o h1 genérico em todas as páginas)
  https://agenda.cm-camaradelobos.pt/acessibilidade

  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 "Agenda Municipal de Cãmara de Lobos" deve ser removido.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #73 R 2.2 - 10 Aspetos Web (Títulos, hierarquia)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 2.2

  Evidências

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

  

  Figura 1 - "Lista de Eventos" implementados com <div> em vez de elementos de cabeçalho apropriados .

  

  Figura 2 - Cabeçalho de cada evento implementado com <div> em vez de elementos de cabeçalho apropriados .

  

  Figura 3 - "eventos" implementados com <div> em vez de elementos de cabeçalho apropriados .

  URLs a verificar:
  https://agenda.cm-camaradelobos.pt/
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos

  Recomendações

  • Substituir os elementos <div> utilizados como títulos de secção por elementos de cabeçalho semanticamente adequados.
  • Na página de Eventos, o título "Eventos" deve ser estruturado como h1.
  • Na página inicial, os títulos "Eventos" e "Categorias" devem ser estruturados como h2.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #45 R 3.1 - 10 Aspetos Web (Tabelas, cabeçalhos das colunas)

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

  Evidências

  Não foram encontradas tabelas

  Recomendações

  N/A.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #46 R 3.2 - 10 Aspetos Web (Tabelas, título)

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

  Evidências

  Não foram encontradas tabelas.

  Recomendações

  N/A.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #26 R 4.1 - 10 Aspetos Web (Formulários, relação campo e etiqueta)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.1

  Evidências

  Existem etiquetas associadas a controlos escondidos das tecnologias de apoio

  No formulário da página Notícias Agenda, as etiquetas “Subcategoria”, "Ano" e “Mês” estão associadas a controlos ocultos das tecnologias de apoio:

  

  Etiqueta Subcategoria associada a um elemento nativo, mas que está oculto das tecnologias de apoio

  Os campos “Subcategoria”, "Ano" e “Mês” 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 no formulário da página multimédia.
  No caso do formulário Submeter Evento, 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.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #44 R 4.2 - 10 Aspetos Web (Formulários, campos obrigatórios)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.2

  Evidências

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

  Verificámos que, em alguns campos do formulário do Submeter Evento em Agenda da 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".

  

  Figura 2 - Análise do campo "Declaro que li e aceito a Política de Privacidade.".

  Para além disso, existem campos em que o atributo required tem uma sintaxe incorreta (foi utilizado required = "", em vez de required ou required = "true"), para além de que nã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. 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.

  Também 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 #28 R 4.2 - 10 Aspetos Web (Formulários, campos obrigatórios)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.2

  Evidências

  Não há informação clara sobre o que é o asterisco nos campos de preenchimento obrigatório

  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 no formulário da página Submeter Evento não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

  

  Figura 1 - Formulário da página Submeter Evento. 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 #30 R 4.3 - 10 Aspetos Web (Formulários, mensagens de erro)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.3

  Evidências

  Existem mensagens de erro apresentadas entre a etiqueta e o campo

  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 Submeter Evento:

  

  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.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #31 R 5.1 - 10 Aspetos Web (Gráficos e Imagens-link, descrição curta)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.1

  Evidências

  Imagem decorativa com texto alternativo indevido

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

  

  ---

  Uso de caracteres especiais no texto alternativo

  Os nomes alternativos das imagens-link incluem caracteres especiais (como _), que estão a ser lidos pelo leitor de ecrã como "sublinhado". É recomendado que o equivalente alternativo seja apresentado em linguagem natural, sem identificadores técnicos ou caracteres desnecessários. Como por exemplo: alt="Curral das Freiras".

  

  ---

  URL

  https://agenda.cm-camaradelobos.pt/
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos?cat=MTI==

  Recomendações

  • Recomenda-se que as imagens decorativas tenham alt="".
  • Quando o SVG tiver apenas finalidade visual ou decorativa, deve ser removido da árvore de acessibilidade, por exemplo com aria-hidden="true".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #50 R 5.2 - 10 Aspetos Web (Gráficos, descrição longa)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.2

  Evidências

  O gráfico não é acompanhado de uma descrição longa

  Verifica-se que a imagem do cartaz contém informação textual e visual relevante, mas essa informação não se encontra integralmente refletida no texto associado à imagem, comprometendo a equivalência informativa do conteúdo disponibilizado.

  

  URL:

  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1462-6-a-edicao-do-premio-literario-joao-augusto-dornelas

  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1474-programa-andar-pela-saude-2026
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos?cat=MTQ=

  Recomendações

  • Recomenda-se que a informação representada no gráfico seja disponibilizada no texto associado à imagem. Uma possível alternativa seria incluir o texto na secção "Descritivo".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #32 R 5.3 - 10 Aspetos Web (Imagens-link, propósito equivalente em texto)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.3

  Evidências

  Imagens link com texto alternativo incorreto.

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

  

  ---

  Verifica-se que o leitor de ecrã não anuncia o texto alternativo correto para a imagem do carrossel, pois o elemento que recebe foco é o link do slide e não a imagem com alt. Na implementação atual, o conteúdo visual do banner é apresentado através de background-image em CSS, mecanismo que não suporta alternativa textual acessível.

  Como o link não dispõe de um nome acessível claro e equivalente ao conteúdo do slide, o leitor de ecrã acaba por anunciar identificadores técnicos como o segmento do URL (“1443-carnaval-2026”) ou referências genéricas ao banner.

  

  ---

  Verifica-se que a imagem-link apresenta um equivalente alternativo insuficiente no atributo alt="evento_Curral" para descrever a finalidade do link.

  

  O mesmo ocorre para as imagens da galeria.

  

  ---

  Verificado que a imagem link "Submeter evento" dispõe de nome acessível apenas através do elemento title. Neste caso a imagem deve ter nome acessível associada ao atributo alt.

  

  URL:
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1163-festa-gastronomica-do-peixe-de-espada-preto-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1161-festa-das-vindimas-estreito-de-camara-de-lobos

  Recomendações

  • O texto alternativo deve transmitir claramente o destino ou finalidade do link. Por exemplo: alt="Agenda 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.
  • Recomenda-se que as imagens do carrossel sejas implementadas de forma a garantir que o elemento interativo (<a>) possui um nome acessível claro relativo ao conteúdo apresentado, deixando de depender de background-image para comunicar informação relevante.
  • Recomenda-se que, sempre que uma imagem ou ícone seja inserido exclusivamente via CSS (como é o caso das imagens da galeria na homepage), seja incluído um texto em HTML no interior do botão, por exemplo através de um elemento , garantindo que a função do componente permanece disponível para tecnologias de apoio. Esse texto pode ficar visualmente oculto, mas deve continuar acessível a leitores de ecrã. Para mais informações: https://www.acessibilidade.gov.pt/tutorial/css-em-accao-conteudo-invisivel-apenas-para-utilizadores-de-leitor-de-ecra/#page1_topic_7

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #61 R 6.1 - 10 Aspetos Web (Contraste, texto normal)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 6.1

  Evidências

  Texto normal não tem contraste suficiente


  
Notas gerais

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

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

  Evidência 01: O texto normal não tem contraste suficiente

  O website apresenta problemas de contraste na página Submeter evento, na primeira interação com a página os textos e labels dos campos de preenchimento “Dados do evento” apresentam-se desativados, pois utilizam uma camada de opacidade sobre os textos. A combinação de cores #C7C7C7(cor de primeiro plano) e #FFFFFF(cor de plano de fundo) torna os textos pouco visíveis. (Figura 1)

  

  Figura 1- Formulário “Submeter evento” com problemas de contraste

  Após o preenchimento do campo ativo "NIF/NIPC*" os textos tornam-se visíveis. No entanto, ao submeter informações incorretas os textos das mensagens de erro também apresentam problemas de contraste nas combinação de cores #E73D4A(cor de primeiro plano) e #FFFFFF(cor de plano de fundo). (Figura 2)


  

  Figura 2- Mensagens de erro do Formulário “Submeter evento” com problemas de contraste

  Evidência 02: O texto normal não tem contraste suficiente em certos estados (Melhoria)

  Há elementos de texto com pouco contraste no estado hover. Por exemplo, na secção “Informações úteis” no rodapé do website, na combinação das cores #EAC363(cor de primeiro plano) e #FFFFFF(cor de plano de fundo) (Figura 3)

  

  Figura 3 - Verificação dos textos do rodapé não passam na avaliação de contraste.

  Na página inicial, os textos nos estados de hover do menu principal e da secção “Categorias” com os textos dos cards possuem um contraste insuficiente em relação ao fundo. (Figura 4 e 5)

  

  Figura 4 - Verificação do contraste em estados de hover dos textos na secção “Categorias” com taxa de contraste de apenas (2,1:1)

  

  Figura 5 - Verificação do contraste em estados de hover nos textos do menu na página Cultura nos Mercados com taxa de contraste de apenas (1,7:1)

  Recomendações

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

Lista de evidências recolhidas:

• evidência: issue #62 R 6.2 - 10 Aspetos Web (Contraste, texto grande)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 6.2

  Evidências

  Texto grande não têm contraste suficiente em certos estados



  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 no texto grande, “Freguesias - Cartazes para Si” pois utilizam a combinação de cores #FFFFFF(cor de primeiro plano) e #FE9F35(cor de plano de fundo). (Figura 1)

  

  Figura 1 - Títulos grandes com problemas de contraste

  Outras páginas OK, na avaliação de contraste para texto grande:

  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1164-festas-de-sao-pedro-camara-de-lobos
  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1473-cultura-nos-mercados
  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/958-concerto-via-crucis-paixao-de-cristo

  Recomendações

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #68 R 7.1 - 10 Aspetos Web (Player, controlo com rato e teclado)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 7.1

  Evidências

  Não foi possível ativar os botões de controlo do leitor com o teclado

  Na secção de vídeos de cada cartaz, 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 “Vídeos” da Festa Gastronómica do Peixe de Espada Preto, onde não foi possível pausar o vídeo utilizando o teclado.

  

  Figura 2: Player da secção “Vídeos” da Festa Gastronómica do Peixe de Espada Preto, onde foi preciso abrir o menu contextual com a opção "Show all controls".

  URLs a verificar:

  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1164-festas-de-sao-pedro-camara-de-lobos
  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1163-festa-gastronomica-do-peixe-de-espada-preto-camara-de-lobos
  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1162-festa-da-cereja-jardim-da-serra
  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1161-festa-das-vindimas-estreito-de-camara-de-lobos
  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1160-mostra-do-trigo-e-do-chicharo-quinta-grande
  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1166-festa-da-castanha-curral-das-freiras

  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 #71 R 7.2 - 10 Aspetos Web (Player, legendas)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 7.2

  Evidências

  Conteúdo visual sem audiodescrição

  Existem players multimédia que apresentam mensagens através de elementos visuais, sem disponibilizar audiodescrição. Em vídeos com música de fundo ou sem narração, onde o conteúdo relevante é transmitido apenas por ações visuais, as pessoas com incapacidade visual podem não conseguir compreender a mensagem apresentada.

  Para garantir acessibilidade, todos os conteúdos visuais essenciais devem ser acompanhados por audiodescrição ou por uma alternativa equivalente que permita compreender integralmente a informação transmitida no vídeo.

  

  Figura 01: Imagem de player com contéudo visual sem audiodescrição na página da Festa da Castanha.

  URL's a verificar:

  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1166-festa-da-castanha-curral-das-freiras
  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1163-festa-gastronomica-do-peixe-de-espada-preto-camara-de-lobos

  Recomendações

  • Incluir audiodescrição sempre que existam informações relevantes comunicadas apenas visualmente.
  • Validar os conteúdos multimédia com utilizadores de tecnologias de apoio, como leitores de ecrã.
  • Assegurar que os controlos do player permitem ativar/desativar faixas de audiodescrição de forma acessível.
  • Disponibilizar uma versão alternativa do vídeo com audiodescrição integrada, quando necessário.
  • Garantir que textos apresentados no ecrã sejam também narrados em áudio.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #84 R 8.3 - 10 Aspetos Web (Estrutura da página, semântica)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

  Evidências

  Controlos de navegação do slider principal implementados sem semântica adequada

  No slider principal da homepage, os controlos de navegação inferior são implementados com elementos <a> sem atributo href, usados apenas para alterar o slide apresentado.

  Embora visualmente sejam apresentados como controlos acionáveis, estes elementos não possuem semântica nativa adequada para a função que desempenham.

  Quando os estilos visuais são removidos, os elementos continuam visíveis, mas deixa de ser programaticamente claro que funcionam como controlos de navegação do slider.

  Como consequência, tecnologias de apoio podem não identificar corretamente a sua função interativa.

  

  Figura 1 – Navegação do slider implementada com elementos <a> sem semântica adequada

  Notas Gerais

  • Elementos que desencadeiam ações na interface devem ser implementados com elementos HTML semanticamente apropriados.
  • Controlos usados para alterar conteúdo, como navegação de sliders ou carrosséis, devem recorrer preferencialmente a elementos como <button>.

  URL a verificar

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

  Recomendações

  • Os controlos de navegação do slider devem ser implementados com elementos HTML adequados à sua função, preferencialmente <button>.
  • A função interativa de cada controlo deve ser identificável programaticamente.
  • Deve evitar-se o uso de elementos <a> sem href para desencadear ações na interface.
  • Recomenda-se validar que os controlos continuam semanticamente reconhecíveis quando os estilos visuais são desativados.

• evidência: issue #78 R 8.3 - 10 Aspetos Web (Estrutura da página, semântica)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

  Evidências

  Títulos de conteúdos da homepage apresentados como imagens sem semântica de cabeçalho

  Na homepage foram identificados destaques de eventos em que o título visual do conteúdo é apresentado através de imagens clicáveis, sem utilização de elementos semânticos de cabeçalho.

  Neste padrão:

  • o título do conteúdo não está marcado com elementos de cabeçalho;
  • a identificação do evento é transmitida visualmente através da própria imagem;
  • existem ainda dois links consecutivos para o mesmo destino, o que introduz redundância de navegação.

  Quando os estilos são removidos, deixa de existir uma estrutura semântica que permita reconhecer programaticamente o título do conteúdo.

  

  Figura 1 – Título de evento apresentado como imagem, sem semântica de cabeçalho

  Notas Gerais

  • Os títulos de conteúdos devem ser estruturados com elementos HTML semanticamente adequados, nomeadamente elementos de cabeçalho (<h1>–<h6>), para que a organização da informação seja corretamente interpretada por tecnologias de apoio.
  • Quando o título é apresentado apenas como imagem, perde-se a semântica estrutural do conteúdo e dificulta-se a navegação por cabeçalhos.

  URL a verificar

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

  Recomendações

  • O título textual de cada conteúdo deve ser marcado com um elemento semântico de cabeçalho adequado (<h2>, <h3>, etc.), de acordo com a hierarquia da página.
  • O cabeçalho deve constituir o principal elemento identificador do conteúdo.
  • Deve evitar-se que a identificação principal do conteúdo dependa exclusivamente de imagens.
  • Sempre que existam múltiplos links consecutivos para o mesmo destino, deve ser avaliada a sua necessidade, evitando redundância de navegação.
  • Recomenda-se verificar este padrão em todos os blocos de destaques e eventos da homepage.

• evidência: issue #22 R 8.3 - 10 Aspetos Web (Estrutura da página, semântica)

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

  Evidências

  Controlos de fecho de modal/carousel implementados com elementos não semânticos

  No componente de modal/carousel observado, o controlo de fecho é implementado através de um elemento genérico (<div>), utilizado para executar uma ação de interface.

  Apesar de o elemento poder ser focável e interativo através de JavaScript, não utiliza um elemento HTML semântico apropriado para ações, como <button>.

  Como consequência, a função do controlo não é corretamente transmitida de forma nativa às tecnologias de apoio, dependendo de atributos adicionais e comportamento programado para simular a sua funcionalidade.

  

  Figura 1 – Controlo de fecho de modal/carousel implementado com <div> em vez de <button>

  Notas Gerais

  • Elementos interativos como controlos de fecho devem ser implementados com elementos HTML semanticamente apropriados, como <button>, de forma a garantir que são corretamente interpretados por tecnologias de apoio e suportam navegação por teclado.
  • A utilização de elementos genéricos como <div> para representar ações interativas compromete a semântica do componente e obriga à simulação do comportamento através de scripts.

  URL a verificar

  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1163-festa-gastronomica-do-peixe-de-espada-preto-camara-de-lobos
  • (outras páginas de eventos ou conteúdos semelhantes com galeria de fotos)

  Recomendações

  • Substituir o elemento <div> por um elemento semântico <button> para o controlo de fecho.
  • Garantir que o botão mantém toda a funcionalidade existente, incluindo:
    • ativação por teclado (Enter e Espaço);
    • foco acessível e visível;
    • comportamento consistente em diferentes tecnologias de apoio.
  • Evitar o uso de elementos genéricos para representar ações interativas em componentes de modal/carousel.
  • Validar o comportamento com navegação por teclado e leitores de ecrã para garantir que a função é corretamente anunciada e operável.

• evidência: issue #21 R 8.3 - 10 Aspetos Web (Estrutura da página, semântica)

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

  Evidências

  Modais sem nome acessível programaticamente determinável

  Na modal observada, embora exista a utilização de role="dialog" e aria-modal="true", não existe qualquer nome acessível associado à janela.

  Não é feita associação a um título visível através de aria-labelledby, nem é fornecido um nome alternativo através de aria-label.

  Como consequência, quando a modal é aberta, os leitores de ecrã podem anunciar apenas que se trata de um diálogo, sem identificar a sua finalidade ou o contexto apresentado ao utilizador.

  

  Figura 1 – Modal sem nome acessível programaticamente determinável

  Notas Gerais

  As janelas modais devem possuir um nome acessível programaticamente determinável, de forma a permitir que tecnologias de apoio identifiquem corretamente o contexto apresentado ao utilizador.

  A ausência de um nome acessível impede que leitores de ecrã anunciem de forma clara a finalidade da janela apresentada, dificultando a compreensão imediata do conteúdo e do contexto de interação.

  URL a verificar

  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1163-festa-gastronomica-do-peixe-de-espada-preto-camara-de-lobos
  • (outros eventos ou páginas semelhantes com galerias de fotos)

  Recomendações

  • Garantir que todas as modais possuem um nome acessível programaticamente determinável.
  • Associar a modal a um título visível, através de aria-labelledby.
  • Quando não existir título visível, fornecer um nome acessível através de aria-label.
  • Verificar este padrão em todas as modais do website.
  • Validar com leitores de ecrã para confirmar que, ao abrir a modal, o contexto é corretamente anunciado ao utilizador.

• evidência: issue #20 R 8.3 - 10 Aspetos Web (Estrutura da página, semântica)

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

  Evidências

  Listagem de conteúdos sem estrutura semântica adequada

  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.

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

  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 #83 R 8.4 - 10 Aspetos Web (Estrutura da página, perda de info)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.4

  Evidências

  Slider principal com estado ativo dependente de apresentação visual

  No slider principal da homepage, os diferentes slides são alternados recorrendo a alterações visuais de estilo (display:none, z-index) e à aplicação de classes como curr, sendo o slide ativo identificado essencialmente através da apresentação visual.

  Quando os estilos visuais são removidos, os vários itens da lista continuam presentes, mas deixa de ser claro qual o conteúdo atualmente apresentado ao utilizador.

  Como consequência, a identificação do estado ativo do componente depende da apresentação visual e não de uma estrutura semanticamente percetível.

  

  Figura 1 – Slider principal com estado ativo dependente de classes CSS e ocultação visual

  Notas Gerais

  • Componentes que apresentam conteúdos alternados, como sliders ou carrosséis, devem permitir identificar programaticamente o estado ativo e a relação entre os diferentes itens.
  • A identificação do conteúdo atualmente visível não deve depender apenas de estilos CSS, posicionamento visual ou ocultação por apresentação.

  URL a verificar

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

  Recomendações

  • O estado ativo do slider deve poder ser identificado programaticamente e não apenas visualmente.
  • Deve existir uma estrutura semanticamente percetível que permita reconhecer qual o slide atualmente apresentado.
  • A visibilidade dos conteúdos não deve depender exclusivamente de estilos CSS como display:none ou classes visuais.
  • Recomenda-se validar que a relação entre os diferentes slides continua compreensível quando os estilos visuais são desativados.

• evidência: issue #82 R 8.4 - 10 Aspetos Web (Estrutura da página, perda de info)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.4

  Evidências

  Ticker de notícias/eventos com movimento automático sem mecanismo percetível de controlo

  Na homepage foi identificado um ticker de notícias/eventos com deslocação horizontal automática contínua.

  O componente apresenta conteúdos que se deslocam automaticamente da direita para a esquerda, sem interação inicial do utilizador.

  Embora no código existam controlos de navegação e pausa, estes encontram-se ocultos:

  <div class="bn-controls" style="visibility:hidden">
      <button><span class="bn-arrow bn-prev"></span></button>
      <button><span class="bn-action bn-pause"></span></button>
      <button><span class="bn-arrow bn-next"></span></button>
  </div>
  

  Deste modo, o utilizador pode ser exposto a conteúdo em movimento contínuo sem um mecanismo percetível para pausar, interromper ou controlar a animação.

  

  Figura 1 – Ticker com deslocação automática e controlos ocultos

  Notas Gerais

  • Conteúdos em movimento automático podem dificultar a leitura, a concentração e a interação, sobretudo quando não existe um mecanismo facilmente identificável para os controlar.
  • Sempre que a interface apresente conteúdos animados, deslizantes ou com atualização automática, deve existir uma forma clara e acessível de os pausar, parar ou navegar manualmente.

  URL a verificar

  • https://agenda.cm-camaradelobos.pt/ (Homepage - ticker de notícias/eventos)

  Recomendações

  • Deve existir um mecanismo visível e facilmente identificável que permita pausar ou interromper o movimento automático.
  • Os controlos de navegação e pausa não devem estar ocultos quando o componente está ativo.
  • O utilizador deve poder avançar, recuar ou interromper a animação manualmente.
  • Recomenda-se validar este comportamento com navegação por teclado e leitores de ecrã.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #55 R 9.1 - 10 Aspetos Web (Modais, foco)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.1

  Evidências

  Ao abrir a modal o foco não é direcionado para o primeiro elemento interativo. A modal esta inacessível para tecnologias de apoio.

  

  URL:
  https://agenda.cm-camaradelobos.pt/menu/submeter-evento

  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 #56 R 9.2 - 10 Aspetos Web (Modais, navegação restrita)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.2

  Evidências

  O foco não fica limitado a modal

  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 #58 R 9.3 - 10 Aspetos Web (Modais, saída)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.3

  Evidências

  A caixa de diálogo pode ser encerrada através de tecnologias de apoio.

  A modal esta inacessível para tecnologias de apoio. Não permite fechar através do botão "Fechar" ou através da tecla de atalho "ESC".

  

  URL:
  https://agenda.cm-camaradelobos.pt/menu/submeter-evento

  Recomendações

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #59 R 9.4 - 10 Aspetos Web (Modais, regresso ao gatilho)

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.4

  Evidências

  Ao fechar a caixa de diálogo o foco não retorna ao elemento que a acionou

  A modal esta inacessível para tecnologias de apoio.

  

  URL:
  https://agenda.cm-camaradelobos.pt/menu/submeter-evento

  Recomendações

  • Ao fechar a caixa de diálogo o foco deve retornar ao elemento que a acionou.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #29 R 10.1 - 10 Aspetos Web (PDF, preservar texto)

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

  Evidências

  Não foi encontrado nenhum ficheiro PDF no website da Agenda de Câmara de Lobos, logo o critério encontra-se Não Aplicável.

  Recomendações

  No response

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #3 R 1.1 - Conteúdo (Clareza, propósito do website)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.1

  Evidências

  Na página principal do website de Agendas da Câmara Municipal de Câmara de Lobos, não aparece presente um resumo breve do próposito do site

  

  Imagem da página principal sem fazer scroll

  Recomendações

  O propósito deve transmitir, de forma clara, o que o utilizador pode efetivamente encontrar e realizar no website. Esse propósito deve ser imediatamente visível na página, 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 #12 R 1.2 - Conteúdo (Clareza, termos complexos)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.2

  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.

  

  Imagem com o termo complexo "CACI" sem definição agregada. Disponível em: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1342-exposicao-em-rolo-arte

  

  Imagem com o termo complexo "OFITE" sem definição agregada. Disponível em: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1476-concerto-pelo-grupo-eleutherius-chorus-e-atuacao-do-nucleo-de-teatro-infantil-da-ofite

  Outros Exemplos:

  • EAPN: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1465-ii-forum-mobilidade-global-integracao-e-diversidade-cultural
  • SRPC, IP-RAM e SESARAM: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1446-sessao-informativa-como-ligar-112
  • IP-RAM: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1460-sessao-de-esclarecimento---queimadas-e-limpeza-de-terrenos

  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 #13 R 1.3 - Conteúdo (Clareza, data de atualização)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.3

  Evidências

  Apesar de no website das Agendas da Câmara Municipal de Câmara de Lobos existir datas de publicação em todos os contéudos de eventos, está em falta algumas datas de atualização em certas páginas.

  Exemplos de páginas sem data de atualização:

  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1162-festa-da-cereja-jardim-da-serra
  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1164-festas-de-sao-pedro-camara-de-lobos
  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1163-festa-gastronomica-do-peixe-de-espada-preto-camara-de-lobos
  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1160-mostra-do-trigo-e-do-chicharo-quinta-grande

  

  Imagem da página da Festa da Cereja sem data de atualização.

  Recomendações

  • Incluir a data de publicação e/ou última atualização em todos os conteúdos relevantes;

  • Garantir que essa informação está semanticamente estruturada;

  • Assegurar consistência na apresentação das datas em todo o site.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #34 R 2.1 - Conteúdo (Usabilidade, tamanho e tipo de letra)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.1

  Evidências

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

  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 Teatro, 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 - Exemplo de corpo de texto na versão desktop com valores corretos

  

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

  O mesmo acontece em todo website, nos textos informativos dos contactos no rodapé. (Figura 3)

  

  Figura 3 - Verificação do texto no rodapé na versão mobile, com texto variável e tamanho de apenas 12px, inferior ao recomendado

  Outras páginas (NOK) em versões para dispositivos móveis:


  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos?cat=NQ==
  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos?cat=Mw==

  Recomendações

  Todo website e 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.

• evidência: issue #33 R 2.1 - Conteúdo (Usabilidade, tamanho e tipo de letra)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.1

  Evidências

  O corpo de texto tem um tamanho inferior a 12pt (equivalente a 16px)

  Notas Gerais

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

  O website possui informações primárias com tamanho inferior a 12pontos(16px) por exemplo na página inicial 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 14px

  As informações de contactos do rodapé, links de Informações úteis, assim como links de atalhos para eventos com textos informativos possuem valor inferior ao recomendado. (Figura 2)

  

  Figura 2 - Textos informativos e informações de contactos com apenas 12px
  

  Há botões com tamanho de texto inferior ao recomendado. Por exemplo os botões “Saiba mais” das páginas Mostras e Feiras , Listas de eventos , Exposições, Músicas. (Figura 3)

  

  Figura 3 - Verificação do tamanho de texto em botões com apenas 14px

  O formulário Submeter evento possui labels associadas aos campos de preenchimento, nomeadamente as checkboxs de declaração de compromisso do utilizador, com textos que possuem tamanho de letra de apenas 14px. (Figura 4)

  

  Figura 4- 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:

  • Notícias Agenda https://agenda.cm-camaradelobos.pt/menu/noticias-agenda
  • Lista de Eventos https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos
  • Lista de Eventos – Cartazes https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/lista-de-eventos-cartazes
  • Multimédia https://agenda.cm-camaradelobos.pt/multimedia

  Recomendações

  É necessário ser corrigido os textos de informações primárias, para um tamanho igual ou superior ao recomendado.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #36 R 2.3 - Conteúdo (Usabilidade, carateres por linha)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.3

  Evidências

  Existem blocos de textos com mais de 100 caracteres por linha


  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 Regras de utilização (Figura 1)

  

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

  Outras evidências (NOK)

  • https://agenda.cm-camaradelobos.pt/menu/noticias-agenda/detalhe/1369-30-de-junho-ficara-na-historia-das-festas-de-sao-pedro-em-camara-de-lobos-20260303145116
  • https://agenda.cm-camaradelobos.pt/menu/noticias-agenda/detalhe/1363-marchas-populares-de-sao-pedro-o-momento-mais-esperado-da-noite-20260303145153
  • https://agenda.cm-camaradelobos.pt/menu/noticias-agenda/detalhe/1471-camara-municipal-de-camara-de-lobos-promove-o-ciclo-camara-de-lobos-mar-e-memoria
  • https://agenda.cm-camaradelobos.pt/menu/noticias-agenda/detalhe/1370-ultimo-capitulo-das-festas-de-sao-pedro-2025-20260303145112

  Recomendações

  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 #37 R 2.4 - Conteúdo (Usabilidade, espaçamento entre linhas)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.4

  Evidências

  O espaçamento entre linhas está abaixo do recomendado


  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 “Momentos...” em que o espaçamento entre linhas é de apenas 18px para um tamanho de letra de 15px. (Figura 1)



  

  Figura 1 - Textos com espaçamento inferior ao recomendado

  Evidência 02
  Na página Espetáculo "A Metamorfose há blocos de textos com espaçamento de apenas 23.4px para um tamanho de letra de 18px. (Figura 2)

  

  Figura 2 - O bloco de conteúdo “Descritivo” 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”, não cumprindo o espaçamento mínimo do presente requisito. Além disso há outros problemas no espaçamento dos blocos de textos em outras páginas interiores, exemplos:

  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1162-festa-da-cereja-jardim-da-serra
  • https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1166-festa-da-castanha-curral-das-freiras

  Recomendações

  Para a evidência 01 apresentada, o espaçamento deveria ser, no mínimo 22.5px. Já para evidência 02 o espaçamento deveria ser, no mínimo 27px. É 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 #15 R 3.1 - Conteúdo (Estrutura da Navegação)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.1

  Evidências

  Excesso de opções no subnível do menu de navegação

  Os menus de navegação devem se manter equilibrado, nem com demasiadas opções de topo sem opções secundárias, nem com poucas opções de topo e muitas opções secundarias. Nenhum nível de navegação deve ter mais de 9 opções, mas neste caso existe um nível com 10 opções.

  

  Imagem com o menu de navegação e o seu subníveis ultrapassando as 9 opções.

  Recomendações

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

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

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

  • Utilizar rótulos claros e consistentes que facilitem a identificação rápida das secções.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #14 R 3.2 - Conteúdo (Estrutura da Navegação)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.2

  Evidências

  A navegação principal do site está colapsada em desktop

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

  No caso de breakpoints inferiores, normalmente considerados para tablet e mobile, o menu pode manter-se colapsado.
  Independentemente da página, o menu deve estar sempre posicionado no mesmo local.

  Em breakpoints superiores, o menu principal do site está colapsado e só é possível expandi-lo a partir do botão “Menu hambúrguer” (ver Figura 01). Por isso, as opções de primeiro nível não são imediatamente visíveis para os utilizadores.

  

  Figura 01: Imagem da página inicial com o menu principal colapsado no topo esquerdo.

  Recomendações

  Em breakpoints superiores, as opções de 1º nível do menu devem estar sempre visíveis na página enquanto existir espaço.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #16 R 3.3 - Conteúdo (Estrutura da Navegação)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.3

  Evidências

  Hiperligações não identificáveis como clicáveis no website

  Foi identificado um problema de acessibilidade relacionado com a identificação visual de links no website. Atualmente, existem situações em que os links não estão devidamente diferenciados do texto normal, sendo identificáveis apenas através da cor ou de interação (hover), o que não cumpre as boas práticas de acessibilidade. Segue em seguida alguns exemplos encontrados:

  

  Imagem dos breadcrumbs como elementos clicáveis mas sem qualquer indicação visual. Disponível em: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1163-festa-gastronomica-do-peixe-de-espada-preto-camara-de-lobos

  

  Imagem dos títulos dos eventos com indicação visual apenas em hover. Disponível em: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos

  

  Imagem de hiperligação no formulário com indicação visual complementar apenas em hover. Disponível em: https://agenda.cm-camaradelobos.pt/menu/submeter-evento

  Outros casos:

  • "Digital" no header;
  • Hiperligações do menu de links úteis no rodapé;
  • "Saber mais" na caixa dos eventos;

  Recomendações

  Garantir que todos os links:

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

  • Incluam sublinhado ou outro indicador visual consistente;

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

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

Lista de evidências recolhidas:

• evidência: issue #27 R 4.1 - Conteúdo (Estrutura da Informação)

  etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: R 4.1

  Evidências

  Otimização da experiência de navegação em páginas com cartazes extensos

  Ponto 01:
  Página: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1164-festas-de-sao-pedro-camara-de-lobos

  Ao navegar pelo menu principal, identificam‑se páginas na secção “Cartazes” com comprimento longo, resultante da utilização de imagens de dimensões muito grandes. Esta situação dificulta a navegação, obrigando a um uso intensivo do scroll.

  

  Figura 01 – Secção “Cartazes” com imagens de grandes dimensões, originando páginas extensas e exigindo utilização intensiva de scroll durante a navegação.

  Outras páginas identificadas::
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1163-festa-gastronomica-do-peixe-de-espada-preto-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1162-festa-da-cereja-jardim-da-serra
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1161-festa-das-vindimas-estreito-de-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1160-mostra-do-trigo-e-do-chicharo-quinta-grande
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1166-festa-da-castanha-curral-das-freiras

  Recomendações

  Redimensionar ou otimizar as imagens, de forma a reduzir o comprimento das páginas e melhorar significativamente a experiência de navegação dos utilizadores.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #7 R 4.2 - Conteúdo (Estrutura da Informação)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 4.2

  Evidências

  O layout do sítio Web é adaptável a plataformas móveis sem necessidade de efetuar varrimento horizontal.
  Ponto 01
  Página: https://agenda.cm-camaradelobos.pt/

  Em dispositivos móveis, as imagens do banner principal não se adaptam corretamente aos diferentes tamanhos de ecrã, originando cortes de conteúdo visual e perda parcial de informação apresentada nos banners. Este comportamento compromete a perceção adequada dos conteúdos e a experiência de navegação em dispositivos de menor dimensão.

  

  Figura 01 – Banner principal com corte de conteúdo visual em dispositivos móveis, comprometendo a perceção da informação apresentada.

  Ponto 02
  Página: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1164-festas-de-sao-pedro-camara-de-lobos

  Em alguns dispositivos móveis, os títulos “Descritivo” e “Mapa” apresentados no cartão relacionado ao banner “Festas de São Pedro – Câmara de Lobos” surgem sobrepostos, enquanto noutros apresentam desalinhamentos visuais, comprometendo a organização e perceção adequada dos conteúdos da interface.

  

  Figura 02 – Títulos “Descritivo” e “Mapa” com sobreposição e desalinhamento em dispositivos móveis, comprometendo a organização visual da interface.

  Outro exemplo:
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1163-festa-gastronomica-do-peixe-de-espada-preto-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1162-festa-da-cereja-jardim-da-serra
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1161-festa-das-vindimas-estreito-de-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1160-mostra-do-trigo-e-do-chicharo-quinta-grande
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1166-festa-da-castanha-curral-das-freiras

  Ponto 03
  Página: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1386-festa-gastronomica-do-peixe-espada-preto-2025

  Na versão móvel da página, os elementos apresentados na secção de detalhe do evento ficam desalinhados em determinados dispositivos, comprometendo a organização visual e a legibilidade da informação.

  

  Figura 03 – Elementos da secção de detalhe do evento com desalinhamentos na versão móvel, comprometendo a organização visual e a legibilidade da informação.

  Outro exemplo:
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1474-programa-andar-pela-saude-2026

  Ponto 04
  Página: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1161-festa-das-vindimas-estreito-de-camara-de-lobos

  Na versão mobile da página do evento “Festa das Vindimas – Estreito de Câmara de Lobos”, o breadcrumb deixa de ser apresentado, dificultando a perceção da localização atual do utilizador na estrutura do sítio Web e comprometendo a orientação durante a navegação.
  O mesmo comportamento foi identificado nos textos descritivos dos cards das notícias, que deixam de ser apresentados em determinados dispositivos móveis, comprometendo a perceção e contextualização dos conteúdos disponibilizados.

  

  Figura 04 – Ausência do breadcrumb na versão mobile da página do evento, dificultando a orientação e perceção da localização atual no sítio Web.

  Outros exemplos:
  https://agenda.cm-camaradelobos.pt/menu/noticias-agenda
  https://agenda.cm-camaradelobos.pt/

  Recomendações

  Garantir que os diferentes componentes da interface apresentem comportamento responsivo consistente em dispositivos móveis, adaptando corretamente imagens, títulos, cartões e restantes elementos de conteúdo aos vários tamanhos e orientações de ecrã, evitando cortes de informação, sobreposições, desalinhamentos e outros problemas que comprometam a organização visual, a legibilidade e a experiência de navegação.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #8 R 5.2 - Conteúdo (Elementos Interativos)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.2

  Evidências

  Os elementos interativos têm uma dimensão mínima de 44px CSS (44 pontos), vertical e horizontal.
  Ponto 01
  Página: https://agenda.cm-camaradelobos.pt/

  Os botões “Submeter”, “Menu Agenda” e o "Seletor de idiomas" apresentam dimensões inferiores ao mínimo recomendado de 44×44px para elementos interativos. Esta configuração pode dificultar a interação, especialmente em dispositivos táteis, aumentando a probabilidade de erros de acionamento e comprometendo a usabilidade da interface.

  

  Figura 01 – Botões “Submeter” e “Menu Agenda” com área interativa inferior ao mínimo recomendado, dificultando a interação em dispositivos táteis.

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

  Os indicadores de navegação do carrossel/banner principal apresentam dimensões inferiores ao mínimo recomendado de 44×44px CSS para elementos interativos. Esta configuração dificulta a seleção precisa dos controlos, especialmente em dispositivos táteis, aumentando a probabilidade de erros de interação e comprometendo a usabilidade da interface.

  

  Figura 02 – Indicadores de navegação do carrossel principal com área interativa inferior ao mínimo recomendado, dificultando a utilização em dispositivos táteis.

  Ponto 03
  Página: https://agenda.cm-camaradelobos.pt/menu/submeter-evento

  No formulário da página “Submeter Evento”, alguns elementos interativos apresentam dimensões inferiores ao mínimo recomendado de 44×44px , nomeadamente botões de opção (radio buttons), checkbox e opções de seleção associadas ao layout pretendido. Esta configuração dificulta a interação e seleção dos elementos, especialmente em dispositivos táteis, aumentando a probabilidade de erros de acionamento e comprometendo a usabilidade do formulário.

  

  Figura 03 – Botões radio do formulário “Submeter Evento” com área interativa inferior ao mínimo recomendado, dificultando a seleção e utilização em dispositivos táteis.

  Ponto 04
  Página: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1164-festas-de-sao-pedro-camara-de-lobos

  Os ícones de redes sociais apresentados na página do evento possuem dimensões inferiores ao mínimo recomendado de 44×44px para elementos interativos. Esta configuração dificulta a seleção precisa dos elementos, especialmente em dispositivos táteis, aumentando a probabilidade de erros de interação.

  

  Figura 04 – Ícones de redes sociais da página do evento com área interativa inferior ao mínimo recomendado, dificultando a interação em dispositivos táteis.

  Outros exemplos:
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1163-festa-gastronomica-do-peixe-de-espada-preto-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1162-festa-da-cereja-jardim-da-serra
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1161-festa-das-vindimas-estreito-de-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1166-festa-da-castanha-curral-das-freiras

  Ponto 05
  Página: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1162-festa-da-cereja-jardim-da-serra

  O botão de fechar (“X”) apresentado na visualização das imagens da galeria possui dimensões inferiores ao mínimo recomendado de 44×44px para elementos interativos. Esta configuração dificulta a interação e o encerramento da visualização da imagem, especialmente em dispositivos táteis.

  

  Figura 05 – Botão de fechar (“X”) da visualização da galeria com área interativa inferior ao mínimo recomendado, dificultando a utilização em dispositivos táteis.

  Outros exemplos:
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1164-festas-de-sao-pedro-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1163-festa-gastronomica-do-peixe-de-espada-preto-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1161-festa-das-vindimas-estreito-de-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1160-mostra-do-trigo-e-do-chicharo-quinta-grande
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1166-festa-da-castanha-curral-das-freiras

  Recomendações

  Garantir que todos os elementos interativos do sítio Web, incluindo botões, controlos de navegação, ícones, radio buttons, checkboxes e controlos da galeria de imagens, possuam uma área mínima de interação de 44×44px CSS, assegurando maior facilidade de utilização, precisão na seleção e melhor experiência de navegação, especialmente em dispositivos móveis e interfaces táteis.

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

Lista de evidências recolhidas:

• evidência: issue #24 R 5.3 - Conteúdo (Elementos Interativos)

  etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: R 5.3

  Evidências

  Inconsistência visual em botões de ação principal e ausência de indicadores claros de clicabilidade

  Foi identificado que alguns botões de ação principal apresentam estilos visuais inconsistentes entre páginas, comprometendo a uniformidade da interface e a identificação clara das ações principais disponíveis.

  Por exemplo, os botões “Limpar filtros” e “Submeter evento” não possuem o mesmo estilo visual:

  https://agenda.cm-camaradelobos.pt/menu/noticias-agenda
  https://agenda.cm-camaradelobos.pt/menu/submeter-evento

  

  Figura 01 – Botão “Limpar filtros” com estilo visual inconsistente em relação a outros botões de ação principal da interface.

  

  Figura 02 – Botão “Submeter evento” com estilo visual inconsistente em relação a outros botões de ação principal da interface.

  Adicionalmente, em determinados contextos, especialmente na versão mobile, o elemento “Limpar filtros” deixa de aparentar visualmente ser um botão, sendo apresentado apenas como texto simples.

  Exemplo:
  https://agenda.cm-camaradelobos.pt/multimedia

  

  Figura 03 – Elemento “Limpar filtros” apresentado visualmente como texto simples em determinados contextos da versão mobile, dificultando a perceção de que se trata de um botão interativo.

  Recomendações

  Garantir consistência visual entre os botões de ação principal do sítio Web, assegurando a utilização de estilos uniformes para elementos com a mesma função e prioridade de ação. Adicionalmente, garantir que os elementos interativos apresentem indicadores visuais claros de clicabilidade em todos os contextos e tamanhos de ecrã, incluindo na versão mobile, através de estilos visuais associados a botões e ações interativas.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #10 R 5.4 - Conteúdo (Elementos Interativos)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

  Evidências

  Elementos gráficos interativos têm de aparentar ser clicáveis.
  Ponto 01
  Página: https://agenda.cm-camaradelobos.pt/

  As secções “Freguesias – Cartazes para si!” e “Eventos” apresentam elementos interativos que não demonstram visualmente serem clicáveis.
  Conteúdos associados e itens da barra de eventos abaixo do banner principal não possuem indicadores visuais claros de interação, como efeitos hover, alteração de cursor, sublinhado, destaque visual ou aparência semelhante a links/botões, dificultando a perceção de que os elementos podem ser selecionados pelos utilizadores.

  

  Figura 01 – Cartazes da secção “Freguesias – Cartazes para si!” sem indicação visual clara de interação, dificultando a perceção de que os elementos são clicáveis.

  

  Figura 02 – Itens da secção de eventos sem indicação visual clara de interação, dificultando a perceção de que os elementos são clicáveis.

  Outros exemplos:
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1164-festas-de-sao-pedro-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1163-festa-gastronomica-do-peixe-de-espada-preto-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1162-festa-da-cereja-jardim-da-serra
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1161-festa-das-vindimas-estreito-de-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/noticias-agenda/detalhe/1349-faltam-5-dias-para-as-festas-de-sao-pedro-20260303145420
  https://agenda.cm-camaradelobos.pt/menu/noticias-agenda/detalhe/1292-preparativos-grupo-de-animacao-sempre-jovem-da-cmcl-carnaval-2025-20260303151355

  Ponto 02
  Página: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1164-festas-de-sao-pedro-camara-de-lobos

  Os ícones da secção de detalhe do evento apresentam aparência e comportamento visual de elementos interativos, como alteração de cor ao passar o cursor (hover), levando o utilizador a interpretar que são clicáveis. No entanto, ao selecionar os ícones, nenhuma ação é executada.
  Esta inconsistência também ocorre nos ícones associados às ligações “Facebook do Evento” e “Instagram do Evento”, onde apenas o texto associado é clicável, apesar dos ícones apresentarem comportamento visual semelhante aos restantes elementos interativos.

  

  Figura 05 – Ícones da secção de detalhe do evento com aparência e comportamento visual de elementos interativos, apesar de não executarem qualquer ação ao serem selecionados.

  Outros exemplos:
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1162-festa-da-cereja-jardim-da-serra
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1163-festa-gastronomica-do-peixe-de-espada-preto-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1161-festa-das-vindimas-estreito-de-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos?cat=MQ==
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1476-concerto-pelo-grupo-eleutherius-chorus-e-atuacao-do-nucleo-de-teatro-infantil-da-ofite

  Ponto 03
  Página: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos?cat=MQ==

  A hiperligação “Saber Mais” e "Limpar filtro" é apresentada visualmente como texto simples, sem diferenciação clara de botão ou elemento de ação principal. Esta apresentação pode dificultar a identificação da ação disponível e reduzir a perceção de interatividade.

  

  Figura 06 – Hiperligação “Saber Mais” sem destaque visual de ação.

  

  Figura 07 – Hiperligação “Limpar filtro” sem diferenciação visual clara de elemento interativo, dificultando a perceção da ação disponível.

  Outro exemplo:
  http://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/lista-de-eventos-cartazes
  https://agenda.cm-camaradelobos.pt/multimedia

  Recomendações

  Garantir que todos os elementos interativos do sítio Web apresentem indicadores visuais claros e consistentes de interatividade, assegurando correspondência entre o comportamento visual e funcional dos elementos. Links, botões, cartões clicáveis, ícones e restantes áreas acionáveis devem possuir características visuais reconhecíveis, como efeitos hover, alteração de cursor, sublinhado, destaque visual ou estilos associados a ações interativas, facilitando a identificação e compreensão das funcionalidades disponíveis pelos utilizadores.

• evidência: issue #9 R 5.4 - Conteúdo (Elementos Interativos)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

  Evidências

  Existem elementos interativos que não possuem contraste.
  Ponto 01
  Página: https://agenda.cm-camaradelobos.pt/

  Os indicadores de navegação do carrossel/banner principal apresentam baixo contraste em determinadas imagens do banner rotativo, dificultando a perceção e identificação dos elementos interativos pelos utilizadores.

  

  Figura 03 – Indicadores de navegação do carrossel principal com baixo contraste em algumas imagens do banner, dificultando a perceção dos elementos interativos.

  Ponto 02
  Página: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1164-festas-de-sao-pedro-camara-de-lobos

  Os ícones apresentados nos elementos “Momentos 2022”, “Momentos 2023” e “Momentos 2024” apresentam baixo contraste em relação ao fundo dos cartões, dificultando a perceção visual dos elementos gráficos interativos. Foi identificado um rátio de contraste de 2.4:1, inferior ao recomendado para uma identificação clara dos elementos pelos utilizadores.

  

  Figura 04 – Ícones dos cartões “Momentos 2022”, “Momentos 2023” e “Momentos 2024” com contraste insuficiente em relação ao fundo, dificultando a perceção visual dos elementos interativos.

  Outro exemplo:
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1163-festa-gastronomica-do-peixe-de-espada-preto-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1162-festa-da-cereja-jardim-da-serra
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1161-festa-das-vindimas-estreito-de-camara-de-lobos
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1160-mostra-do-trigo-e-do-chicharo-quinta-grande
  https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1166-festa-da-castanha-curral-das-freiras

  Ponto 03
  Página: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/evento/1462-6-a-edicao-do-premio-literario-joao-augusto-dornelas

  Os ícones de redes sociais apresentados na página do evento apresentam contraste insuficiente em relação ao fundo envolvente, dificultando a perceção e identificação dos elementos interativos pelos utilizadores. Foi identificado um rácio de contraste aproximado de 2.06:1, inferior ao recomendado para uma identificação visual adequada dos controlos interativos.

  

  Figura 08 – Ícones de redes sociais da página do evento com contraste insuficiente em relação ao fundo, dificultando a perceção dos elementos interativos.

  Ponto 04
  Página: https://agenda.cm-camaradelobos.pt/menu/lista-de-eventos/lista-de-eventos-cartazes

  Os ícones de redes sociais apresentados na página possuem aparência visual de elementos interativos, como destaque gráfico e comportamento associado a ações clicáveis, levando o utilizador a interpretar que os elementos podem ser selecionados.

  No entanto, ao clicar nos ícones, nenhuma ação é executada.
  Adicionalmente, os ícones apresentam baixo contraste em relação ao fundo, dificultando a sua perceção visual pelos utilizadores.

  

  Figura 09 – Ícones de redes sociais com aparência visual de elementos interativos, apesar de não executarem qualquer ação ao serem selecionados e apresentarem contraste insuficiente em relação ao fundo.

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

  No carrossel de vídeos da página inicial, foi identificado elementos interativos superiores aos vídeos que apresentam contraste insuficiente, dificultando a perceção e identificação enquanto botões clicáveis.

  Adicionalmente, ao selecionar o elemento, é aberta uma modal com o mesmo conteúdo de vídeo já disponível no carrossel, não sendo clara a utilidade funcional desta ação no contexto apresentado.

  A reduzida perceção visual do componente, associada à ausência de valor funcional evidente, pode gerar ambiguidade para o utilizador relativamente ao comportamento esperado do elemento.

  

  Figura 10 – Elemento interativo sobreposto ao carrossel de vídeos com contraste insuficiente e sem utilidade funcional evidente, gerando ambiguidade relativamente ao comportamento esperado.

  Recomendações

  Garantir contraste visual suficiente entre os elementos gráficos interativos e os respetivos fundos, assegurando que indicadores de navegação, ícones e restantes controlos visuais permaneçam facilmente identificáveis em diferentes contextos e imagens de fundo. Poderão ser utilizados contornos, sombras, fundos sólidos/semitransparentes ou cores com maior diferenciação visual para melhorar a perceção dos elementos interativos.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #38 R 1.1 - Transação (Formulários)

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

  Evidências

  Há campos dos formulários que são ignorados quando se navega por teclado

  Ao navegar pelo formulário com o teclado usando a tecla Tab, a sequência de tabulação deve seguir a ordem de preenchimento, passando por todos os campos disponíveis.

  Verificámos que, nas páginas Lista de Eventos e Lista de Eventos – Cartazes, não é possível focar em alguns campos dos formulários destas páginas através de Tab e Shift+Tab. No caso da página Lista de Eventos, não é possível focar em nenhum dos campos dentro do formulário (“Nome do Evento”, “Categoria”, “Freguesia”, “Mês”, “Limpar por Filtro”). No caso da página Lista de Eventos – Cartazes, não é possível focar nos campos “Freguesia”, “Mês” e na opção “Limpar filtro”.

  

  Figura 1 - Análise da opção "Limpar filtro", na página Lista de Eventos - Cartazes, através do Google Inspector.

  

  Figura 2 - Análise da lista suspensa "Categoria", na página Lista de Eventos - Cartazes, através do Google Inspector.

  Recomendações

  Recomendamos que os componentes dos formulários sejam restruturados utilizando elementos HTML nativos e semânticos, evitando recorrer a div's para construir campos de formulário.

  Para componentes como campos de texto e listas suspensas, sugerimos a consulta da página Creating Accessible Forms da WebAIM, que apresenta boas práticas de acessibilidade.

  Nos formulários das páginas Lista de Eventos e Lista de Eventos – Cartazes, a opção “Limpar filtro” deve ser implementada através do elemento HTML nativo <button> em vez de <span>, garantindo que o controlo seja corretamente identificado como um botão pelos leitores de ecrã e tecnologias de apoio.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #39 R 1.2 - Transação (Formulários)

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

  Evidências

  Não foram encontrados formulários com mais de 2 ecrãs no website

  Não foram encontrados formulários com mais de dois ecrãs no site Agenda 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 #40 R 1.3 - Transação (Formulários)

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

  Evidências

  Não foram encontrados formulários com mais de uma página

  Não foram encontrados formulários com mais de uma página dentro da Agenda 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 #41 R 2.1 - Transação (Campos)

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

  Evidências

  O tamanho do campo não reflete o tamanho previsível dos dados

  Verificámos que na página Submeter Evento, o campo “Nome do Evento” apresenta uma largura excessiva para o tipo de dados que o utilizador precisa de inserir.

  

  Figura - Parte do formulário presente na página Submeter Evento. O campo "Nome do Evento" está destacado através de um retângulo de borda preta.

  Recomendações

  Recomendamos que este campo de formulário seja ajustado, tornando o mais estreito e proporcional ao conteúdo previsto.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #48 R 2.2 - Transação (Campos)

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

  Evidências

  Há campos dependentes de outros campos que estão imediatamente visíveis, mas estão inativos

  Os campos dependentes do preenchimento de outros campos devem aparecer apenas após o campo principal ter sido preenchido. Desta forma, reduz-se a probabilidade de preencher dados contraditórios.

  No formulário da página Submeter Evento, o campo “A Câmara Municipal de Câmara de Lobos é coorganizadora do evento?” está visível mas inativo, não sendo possível de preencher, visto que tem dependência do preenchimento do campo “NIF/NIPC”.

  

  Figura 1 - Formulário da página Submeter Evento.

  

  Figura 2 - Análise do campo "A Câmara Municipal de Câmara de Lobos é coorganizadora do evento?", no formulário da página Submeter Evento, através do Google Inspector.

  Recomendações

  Recomendamos esconder o campo “A Câmara Municipal de Câmara de Lobos é coorganizadora do evento?”. Apenas deve aparecer após o utilizador preencher o campo “NIF/NIPC”, dependendo da resposta dada.

  Reparámos também que o aparecimento do restante formulário, abaixo do campo “A Câmara Municipal de Câmara de Lobos é coorganizadora do evento?”, está também dependente do preenchimento do primeiro campo “NIF/NIPC”. Assim, quer o campo “A Câmara Municipal de Câmara de Lobos é coorganizadora do evento?” quer o restante formulário, só devem ficar visíveis – quer visualmente na interface gráfica quer para os leitores de ecrã - após preenchimento do campo “NIF/NIPC”.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #43 R 2.3 - Transação (Campos)

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

  Evidências

  O texto placeholder está a substituir o rótulo

  Não deve ser usado o texto placeholder em substituição de uma label, porque ao escrever no campo esse texto irá desaparecer e torna a tarefa difícil para pessoas com problemas de memória ou na revisão das respostas do formulário. Para além disso, alguns leitores de ecrã podem não estar preparados para ler esse texto.
  Manter a label visível no ecrã, amplia-se a área de clique, o que pode beneficiar pessoas com dificuldades motoras ao selecionar um campo específico.

  No campo “Nome do Evento” do formulário da página Lista de Eventos, há apenas um texto placeholder associado ao campo e não existe qualquer legenda associada ao mesmo.

  

  Figura - Análise do campo "Nome do Evento", na página Lista de Eventos, através do Google Inspector.

  Recomendações

  Recomendamos a revisão dos formulários para garantir que:

  • são atribuídas legendas aos campos utilizando o elemento <label>;
  • o texto placeholder, quando utilizado, auxilia no preenchimento do campo em vez de substituir a legenda;
  • caso seja usada a legenda dentro do campo, esta deve estar identificada como <label> e não deve desaparecer quando o campo está em foco, como acontece no exemplo do Campos de formulário - Material Design e/ou Caixa de seleção - Material Design

  Para mais informações, recomendamos consultar a página sobre boas práticas nos formulários da WebAIM.

• evidência: issue #42 R 2.3 - Transação (Campos)

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

  Evidências

  Caixas de combinação não estão estruturadas de forma acessível

  Verificámos que, nas comboboxes presentes nas páginas Notícias Agenda, Multimédia e Submeter Evento 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 - Navegação na página Multimédia através de Tab e Shift+Tab e pelo leitor de ecrã NVDA. Quando o utilizador foca os campos "Filtrar por categoria" e "Filtrar por ano" não são anunciados os rótulos dos campos.

  

  Figura 2 - Análise do campo "Subcategoria", na página Notícias Agenda, através do leitor de ecrã. Quando o utilizador tenta navegar pelas opções do campo, o leitor de ecrã anuncia apenas “Em branco”, em vez de ler cada opção disponível.

  

  Figura 3 - Análise do campo "Subcategoria", da página Notícias Agenda, através do Google Inspector.

  Recomendações

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #60 R 2.4 - Transação (Campos)

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

  Evidências

  Há campos que não estão visualmente identificados como obrigatórios
  Verificámos que, na página Submeter Evento, os campos “Website do evento”, “Facebook do evento” e “Instagram do evento” estão programaticamente definidos como obrigatórios (através de aria-required=”true”) mas não têm nenhuma indicação visual de que são campos de preenchimento obrigatório.

  

  Figura - Análise dos campos "Website do evento" e "Facebook do Evento", da página Submeter Evento, através do Google Inspector.

  Recomendações

  Recomendamos que, tal como nos restantes campos de preenchimento obrigatório, seja adicionado um asterisco(*) à frente do rótulo. Adicionalmente, e como já referido na issue “Não há informação clara sobre o que é o asterisco nos campos de preenchimento obrigatório”, deve também ser adicionada uma legenda no início do formulário a indicar claramente o significado de *.

• evidência: issue #52 R 2.4 - Transação (Campos)

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

  Evidências

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

  Verificámos que, no formulário da página Submeter Evento, os campos:

  • “A Câmara Municipal de Câmara de Lobos é coorganizadora do evento?”
  • “Categoria”
  • “Data de início”
  • “Freguesia”
  • “Layout pretendido para a página de detalhe”
  • “Declaro sob compromisso de honra a veracidade de todas as declarações prestadas e assumo toda a responsabilidade consequente da sua inexatidão ou falsidade”
  • “Declaro que li e aceito a Política de Privacidade”

  Não estão programaticamente definidos como obrigatórios.

  

  Figura 1 - Análise do campo “Declaro sob compromisso de honra a veracidade de todas as declarações prestadas e assumo toda a responsabilidade consequente da sua inexatidão ou falsidade”, na página Submeter Evento, através do Google Inspector.

  

  Figura 2 - Análise do campo “Declaro que li e aceito a Política de Privacidade”, na página Submeter Evento, 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.

• evidência: issue #49 R 2.4 - Transação (Campos)

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

  Evidências

  Não há informação clara sobre o que é o asterisco nos campos de preenchimento obrigatório

  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 no formulário da página Submeter Evento não existe informação sobre o significado do asterisco (*) colocado à frente dos campos.

  

  Figura - Formulário da página Submeter Evento.

  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 #5 R 3.1 - Transação (Resposta)

  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

  Evidências

  Inexistência de ações longas

  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.

  Recomendações

  N/A

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #6 R 3.2 - Transação (Resposta)

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

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

  Evidências

  Feedback após submissão não acessível

  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

  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://agenda.cm-camaradelobos.pt/menu/submeter-evento

  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 #54 R 4.2 - Transação (Erros)

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

  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

  N/A

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #70 R 4.3 - Transação (Erros)

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

  Evidências

  Existem mensagens de erro apresentadas entre a etiqueta e o campo

  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 Submeter Evento:

  

  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.

• evidência: issue #67 R 4.3 - Transação (Erros)

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

  Evidências

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

  

  Checkbox no formulário Submeter Evento 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.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #69 R 4.4 - Transação (Erros)

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

  Evidências

  Campos de formulário assinalados como inválidos sem indicação concreta para correção

  No campo NIF/NIPC, ao introduzir um valor inválido, o sistema assinala programaticamente o campo como inválido através de aria-invalid="true" e associa um contentor de erro com aria-describedby.

  No entanto, o contentor associado à mensagem de erro encontra-se vazio.
  Na prática, o utilizador é informado de que o campo contém erro, mas não recebe indicação concreta sobre o motivo da invalidação nem sobre a forma de o corrigir.

  Foi ainda observado que, ao introduzir um valor incorreto neste campo, o formulário pode impedir a progressão normal para outros campos, sem apresentar instruções claras para resolução.

  

  Figura 1 – Campo NIF/NIPC assinalado como inválido sem mensagem de erro explicativa

  Recomendações

  • Sempre que o campo NIF/NIPC for invalidado, deve ser apresentada uma mensagem de erro clara e objetiva.
  • A mensagem deve indicar concretamente o que o utilizador necessita corrigir.
  • Devem ser evitadas mensagens vazias ou apenas a sinalização visual do erro.
  • A mensagem deve permanecer programaticamente associada ao campo através de aria-describedby.
  • Recomenda-se validar este comportamento também nos restantes formulários do website.

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

Lista de evidências recolhidas:

• evidência: issue #81 Outras violações

  etiqueta: melhoriaetiqueta: outras violações

  Evidências

  Outras violações - Há títulos desorganizados em ecrãs

  Descrição da problemática

  Na página inicial, ao aceder as notícias na secção “Momentos” os detalhes das páginas possuem títulos que ocupam a largura da página com um espaço que sobrepõe a área do conteúdo ou mantém os espaçamento muito próximo a outras informações por exemplo a “data de publicação”, causando desorganização visual no ecrã.

  Por exemplo, na página Ana Lua Caiano e João Borsch na Semana da Juventude de Câmara de Lobos! (Figura 1 e 2)

  

  Figura 1 - Título desordenado nas versões desktop

  

  Figura 2 - Título comprimido nas versões mais pequenas

  Esta desorganização da informação pode dificultar a leitura rápida, aumentar a carga cognitiva, especialmente em dispositivos móveis e para utilizadores de tecnologias assistivas.

  Outros exemplos:


  • https://agenda.cm-camaradelobos.pt/menu/noticias-agenda/detalhe/1385-ana-lua-caiano-e-joao-borsch-na-semana-da-juventude-de-camara-de-lobos-20260303144758
  • https://agenda.cm-camaradelobos.pt/menu/noticias-agenda/detalhe/1471-camara-municipal-de-camara-de-lobos-promove-o-ciclo-camara-de-lobos-mar-e-memoria
  • https://agenda.cm-camaradelobos.pt/menu/noticias-agenda/detalhe/1369-30-de-junho-ficara-na-historia-das-festas-de-sao-pedro-em-camara-de-lobos-20260303145116

  Recomendações

  Definir limites de extensão para os títulos, usar subtítulos ou texto introdutório para informações complementares e aplicar hierarquia semântica clara (título principal mais curto). Garantir também um layout responsivo para títulos que controle a quebra de texto, melhorando a legibilidade e a acessibilidade geral da página.

• evidência: issue #80 Outras violações

  etiqueta: melhoriaetiqueta: outras violações

  Evidências

  Outras violações - Botão com texto alternativo em inglês

  Descrição da problemática

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

  Por exemplo na página Submeter evento os botões de ampliar e reduzir mapa, possuem textos alternativos em inglês "Zoom in", “Zoom out”, sem indicação adequada do atributo lang. Dificultando a navegação para utilizadores do idioma português, língua em que o site é implementado. (Figura 1)

  

  Figura 1 - Botões do mapa com textos alternativos em inglês

  Além disso na página inicial o botão, "seletor de idiomas", possui aria-label="Select Language", pelo que deve ser corrigido para o idioma principal do website. (Figura 2)

  

  Figura 2 - Botão com texto alternativo em inglês

  Recomendações

  Recomendamos traduzir todos os textos alternativos dos botões para português, idioma principal do website.

• evidência: issue #77 Outras violações

  etiqueta: melhoriaetiqueta: outras violações

  Evidências

  Outras violações - Falha na abertura de vídeos em modal na seção Multimédia

  Descrição da problemática
  Na página inicial, a secção “Multimédia”, os botões destinados a abrir vídeos em uma modal não funcionam corretamente ao serem acionados, os vídeos são duplicados na própria página, não são ampliados e a modal não se apresenta de forma adequada, ficando desalinhada, não centralizada no ecrã e exibindo apenas um botão “fechar” lateral ao vídeo ainda em miniatura. (Figura 1 e 2)



  

  Figura 1 - Botões que acionam a modal e análise da navegação com leitor de ecrã NVDA

  

  Figura 2 - 
Apresentação incorreta da modal e desalinhada no ecrã

  Esse comportamento compromete a usabilidade, gera confusão na interação e prejudica a acessibilidade, especialmente para utilizadores de teclado e tecnologias assistivas.

  Recomendações

  Corrigir a implementação dos botões e das modais para garantir que o vídeo seja aberto em uma janela sobreposta, centralizada no ecrã, com bloqueio do conteúdo de fundo, foco adequado e controles acessíveis. Evitar a duplicação de conteúdo e assegurar que a abertura e o fechamento da modal sigam boas práticas de acessibilidade proporcionando uma interação clara, consistente e previsível para todos os utilizadores

• evidência: issue #76 Outras violações

  etiqueta: melhoriaetiqueta: outras violações

  Evidências

  Outras violações - Há hiperligações que redirecionam para páginas de erro

  Descrição da problemática

  O menu principal do website, possui opções de segundo nível na área “Agenda” Agenda - Dança e Conferências / Workshops com hiperligações que apontam para conteúdos inexistentes. Ao aceder os conteúdos o utilizador é redirecionado para página de erro e recebe a mensagem “Sem resultados. Faça nova pesquisa.” (Figura 1)


  

  Figura 1 - Páginas que redirecionam para conteúdos "Sem resultados"

  Esta situação impede o acesso à informação e constitui uma barreira significativa na acessibilidade do conteúdo.

  Recomendações

  Recomenda‑se rever todo website, para garantir que todas as hiperligações apontam para conteúdos atualizados e disponíveis no website.

• evidência: issue #75 Outras violações

  etiqueta: melhoriaetiqueta: outras violações

  Evidências

  Outras violações - Foco não está visível na navegação por teclado e leitor de ecrã

  Descrição da problemática
  Ao navegar pelo website utilizando apenas o teclado e leitor de ecrã, o indicador de foco não 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, o foco não está visível e as componentes não são circunscritas durante a navegação por teclado, por exemplo nos cards da secção “Categorias” e nas hiperligações do rodapé. (Figura 1 e 2)

  

  Figura 1 – Exemplo de ausência do foco visível na navegação por teclado no card “Espetáculo”

  

  Figura 2 – Exemplo de foco visível mas não circunscreve corretamente as componentes

  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 ou anúncio das informações com o leitor de ecrã NVDA. 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 nas páginas, 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 #74 Outras violações

  etiqueta: melhoriaetiqueta: outras violações

  Evidências

  Outras violações - Link “Passar para o Conteúdo Principal” não é visível

  Descrição da problemática
  Na estrutura do website encontra‑se disponível o link “Passar para o Conteúdo Principal”, cuja finalidade é permitir aos utilizadores contornar blocos repetitivos de navegação e aceder diretamente à área principal do conteúdo.

  No entanto, este link além de não direcionar para o contéudo principal permanecendo no header, 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)

  

  A Figura 1 - Inexistência operacional do link “Passar para o Conteúdo Principal” 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 “Passar para o Conteúdo Principal” seja:

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

  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.