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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Há opções do menu que não estão estruturadas como lista (elementos "ul" e "li")

  etiqueta: chk 10 webetiqueta: R 1.1etiqueta: NOK

  O menu de navegação deve estar estruturado como uma lista de opções.

  • Ver requisito 1.1 da lista 10 aspetos

  Verificámos que as opções presentes nalguns menus do website não estão estruturadas como lista ul li, nomeadamente:

  • Os menus com a indicação das redes sociais presentes no topo e no rodapé do website;
  • O menu com a lista de idiomas do website;
  • A opção “Livro Reclamacoes Branco” na secção “Informação Legal”.

  

  Secção de links para redes sociais no rodapé da página

  

  Secção de links para redes sociais no topo da página

  

  Lista de idiomas

  

  Opção “Livro Reclamacoes Branco” na secção “Informação Legal”

  Para que a navegação seja acessível e corretamente interpretada pelas tecnologias de apoio, os elementos dos menus e submenus deverão estar todos estruturados como listas, recorrendo aos elementos ul e li.
  Recomendamos que os menus referidos acima sejam estruturados como listas, utilizando tags ul e li.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Setas de expansão de subopções estruturadas incorretamente

  etiqueta: chk 10 webetiqueta: R 1.2etiqueta: NOK

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

  • Ver requisito 1.2 da lista 10 aspetos

  O menu principal, versão desktop, tem alguns problemas que impedem a correta navegação por teclado (tab e shift+tab), que passamos a referir:
  1 - As setas para expansão das opções do menu são controlos personalizados, que recorrem a elementos <span>, em vez de elementos interativos nativos do HTML.

  

  Setas de expansão das opções do menu implmmentadas com span
  No que respeita à acessibilidade total de um botão de seta, este tipo de personalização com elemento <span> exige muitos mais ajustes do que um controlo nativo, que já é acessível por omissão.
  Estes elementos span> foram enriquecidos de forma a serem focáveis e pressionáveis via teclado (tab e shfit+tab), mas apresentam muitos problemas quando se tenta fazer o mesmo através da navegação por elementos presente nos leitores de ecrã (não é possível expandir as opções e o utilizador fica “preso” no botão, tendo de pressionar uma tecla fora do seu fluxo de navegação para voltar ao curso normal).
  Esta captura da navegação pelas setas deve-se ao facto de as mesmas terem o atributo role = “application”, que não se aplica a menus de navegação como este.
  Verificámos também, no caso deste menu, que foram implementados elementos <button> usados como setas, mas que estão escondidos recorrendo à propriedade “display: none” do CSS.
  Enquanto que os elementos <span> estão dentro dos elementos <a>, os elementos <button> estão a seguir aos elementos <a>.
  As setas não devem estar nos textos dos links, já que impossibilitam a existência de clareza relativamente àquilo que são as funções de expansão das subopções (através do acesso a cada seta) e a remissão para a página associada a cada link (através do acesso a cada link).
  O conteúdo destas funções deve, portanto, ser claramente separado, mantendo-se as setas fora dos links.
  Para atingir essa separação de funções nos itens de menu de dupla função, os links não podem ter o atributo aria-expanded, já que os mesmos não têm a função de expandir as subopções, mas sim de abrir a página contida no atributo href. O atributo aria-expanded deve estar presente apenas nos controlos de seta de expansão de subopções.
  Recomendamos a substituição dos elementos <span> por elementos <button>, que já têm todas as propriedades de acessibilidade nativamente, bem como a não utilização do atributo role = "application" nas setas, pois o mesmo atrapalha o fluxo normal de navegação dos utilizadores de leitores de ecrã em menus de navegação.
  Recomendamos ainda a eliminação do atributo aria-expanded de todos os links do menu.

  2 – Existem itens de menu que têm setas de expansão associadas, sem no entanto terem associada uma lista de subopções. É o caso do item “REUNIÕES DE CÂMARA”, que a seguir a ele tem uma seta para expandir as suas opções (focável via tab), mas sem uma lista de opções para ser visualizada.

  

  Item de menu que apresenta a seta de expansão sem ter uma lista de subopções associada

  Recomendamos a revisão de todo o menu, eliminando todas as setas de expansão onde não existam subopções para expandir.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: Inexistência de imagens link no menu principal

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

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

  • Ver requisito 1.3 da lista 10 aspetos

  Não encontrámos imagens link no menu principal, pelo que este requisito é não aplicável.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem páginas com mais de um cabeçalho de nível 1

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.1

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

  • Ver requisito 2.1 da lista 10 aspetos

  A página 'Sabugal Presépio' 2025 tem dois cabeçalhos de nível 1.

  

  Página com dois cabeçalhos de nível 1

  Recomendamos a restruturação dos cabeçalhos de todas as páginas do site, de forma a que exista apenas um cabeçalho de nível 1. Uma das possibilidades no caso da página acima referida é, caso julguem fazer sentido, a junção dos dois cabeçalhos, de modo a formarem um único cabeçalho, “'Sabugal Presépio' 2025 - Entrada Gratuita!”.

• evidência: A página principal não tem o logotipo associado

  etiqueta: chk 10 webetiqueta: R 2.1etiqueta: melhoria

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

  • Ver requisito 2.1 da lista 10 aspetos

  As páginas do website devem ter apenas um <h1> atribuído. Este elemento deve ser apenas atribuído a títulos relevantes na estrutura da página, e não a textos genéricos, botões ou outro conteúdo.
  Nas páginas interiores, o <h1> deve estar atribuído ao título do conteúdo principal dessa página. Já na homepage, o <h1> deve estar atribuído ao logótipo para, em conjunto com um texto alternativo correto, melhorar o SEO da página.
  Verificamos que na página inicial o cabeçalho <h1> não está associado ao logotipo.

  

  Cabeçalho nível 1 da página inicial não associado ao logotipo

  Recomendamos a modificação do elemento <h1> da página principal, de forma a conter o logotipo do site, e a modificação do texto alternativo do logotipo para “Município do Sabugal”.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem secções sem cabeçalho

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

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

  Cada um dos três primeiros carrosséis da página inicial corresponde à sua respetiva secção, mas não foi colocado um cabeçalho em cada uma das três secções.

  

  Secção Avisos

  

  Secção Destaques

  

  Secção Links rápidos

  As secções “Avisos” e “Links rápidos” possuem atributos aria-label, com os valores, respetivamente, de “Avisos” e “Links rápidos: Página Inicial - Links Rápidos”, ao passo que a secção “Destaques” não possui qualquer indicação semântica, pelo que os leitores de ecrã não anunciam o início desta secção.
  Apesar do esforço na colocação de atributos aria-label, e de essa solução ser melhor do que a ausência de qualquer informação semântica, fazemos notar que estes atributos aria-label atribuem nomes acessíveis de forma genérica, não estando preparados para definir o início de uma secção na verdadeira aceção da palavra, com a semântica que possibilite aos utilizadores de leitores de ecrã o salto entre secções e a produção de uma lista de secções existentes na página. Esse nível de semântica só é conseguido através da utilização de cabeçalhos.

  Posto isto, recomendamos que procedam:

  • À inserção de cabeçalhos de nível 2 antes de cada carrossel mencionado acima, com os textos, respetivamente, “Avisos”, “Destaques” e “Links Rápidos”.
    Caso não pretendam que os cabeçalhos fiquem visíveis no ecrã, podem proceder à sua ocultação, através da classe CSS específica do vosso gestor de conteúdos que possibilita que os elementos sejam mostrados apenas às tecnologias de apoio (por exemplo, class = “sr-only”).
  • Remoção dos atributos aria-label dos elementos que contêm os carrosséis das secções “Avisos” e “Links rápidos”, de modo a que a informação das secções seja apresentada apenas nos cabeçalhos.

• evidência: Existem cabeçalhos incorretamente atribuídos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

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

  Existem cabeçalhos que não configuram secções, e devem ser removidos.

  

  Um dos cabeçalhos da secção "Sabugal"

  Como é possível observar na figura, o cabeçalho de nível 3 “Onde Dormir” constitui-se, atualmente, como uma subsecção da secção “Sabugal”.
  Este cabeçalho, bem como todos os demais da secção “Sabugal” (que obedecem à mesma estrutura), encontram-se imediatamente uns a seguir aos outros, sem qualquer texto entre eles, pelo que não faz sentido que sejam considerados como início de novas secções. Para além disso, cada cabeçalho desta secção tem um link que o sucede, e em que se verifica que o texto de cada link é igual ao texto de cada cabeçalho.

  Pelo exposto, e neste caso em particular, recomendamos a remoção completa dos elementos <h3> (inclusive o seu texto) dos itens da secção “Sabugal”, não só por não serem considerados secções, mas também para evitar a duplicação de informação.
  Diretamente relacionado com este ticket está o ticket R 8.3 - 10 Aspetos - Existem cards estruturados de forma incorreta, que recomenda a restruturação dos cards onde se localizam estes cabeçalhos.

• evidência: Existem textos de início de secção que não estão colocados em elementos cabeçalho

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

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

  A página Associações Desportivas contém, entre outras, as secções “Contrato-Programa de Desenvolvimento Desportivo | Época 2025/2026:”, “Contrato-Programa de Desenvolvimento Desportivo | Época 2024/2025:”, “Sporting Clube do Sabugal” e “Associação Cultural e Desportiva de Malcata”, cuja perceção apenas é possível devido ao destaque em negrito destes elementos.

  

  Secções que se diferenciam do restante texto apenas pelo destaque em negrito

  Com efeito, estes elementos não possuem nenhuma indicação semântica que permita transmitir aos leitores de ecrã que os mesmos marcam o início de secção, não sendo portanto possível aos utilizadores destas tecnologias a navegação entre estas secções de forma rápida.
  Verificámos que as secções estão separadas entre si pelo elemento <hr>, e que alguns leitores de ecrã possuem teclas de atalho para navegar entre estes elementos, mas não é uma navegação a que o típico utilizador esteja habituado, para além de não possibilitar a colocação das várias secções num índice de secções que permita a pesquisa rápida.
  Pelo exposto, recomendamos que os textos que sejam diferenciados apenas visualmente como sendo secções sejam colocados em elementos cabeçalho, de forma a possibilitar a sua descoberta através de teclas rápidas de navegação dos leitores de ecrã, permitindo assim uma navegação mais rápida entre estas secções.

• evidência: Existem saltos na hierarquia de cabeçalhos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

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

  A página Município contém um salto na hierarquia dos cabeçalhos.

  

  Salto na hierarquia de cabeçalhos

  Como se pode observar na figura, a hierarquia passa de um cabeçalho de nível 2 para um cabeçalho de nível 5, sem cabeçalhos de nível 3 e nível 4 entre eles.
  Recomendamos a correção da hierarquia de cabeçalhos em todas as páginas do site.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem tabelas sem elemento ``

  etiqueta: chk 10 webetiqueta: R 3.2etiqueta: NOK

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

  A tabela presente na página Feiras e Mercados não tem legenda.

  

  Tabela sem legenda

  As tabelas de dados devem ter uma legenda ou título marcado com o elemento <caption> de forma a dar um maior contexto e ajudar a associar rapidamente a tabela ao seu conteúdo.
  Recomendamos a inserção de um elemento <caption> a todas as tabelas do site, com o título de cada tabela.
  No caso particular da tabela referida cima, deixamos uma sugestão de título e de como poderia ficar o código:

  <table style="border-style:none;border-width:0px">
      <caption>Plano Anual de Feiras e Mercados</caption>
      <thead>
           <tr>
               <th class="has-text-align-left" data-align="left">LOCALIDADES</th>
               <th class="has-text-align-left" data-align="left">MERCADOS</th>
               <th class="has-text-align-left" data-align="left">FEIRAS</th>
           </tr>
      </thead>
  ...
  </table>
  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O texto placeholder está a substituir a label

  etiqueta: chk 10 webetiqueta: R 4.1etiqueta: NOK

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

  No formulário de Subscrever Newsletter existem apenas textos placeholder nos campos, e não existe uma etiqueta visível e associada aos mesmos:

  

  Campos nome, endereço de email e telemóvel não possui etiqueta visível e possui apenas um placeholder

  O mesmo se verifica no campo de pesquisa da página Editais Outros 2025, onde o campo apresenta apenas o placeholder. É necessário que exista uma etiqueta visível associada ao campo:

  

  Campo de pesquisa com placeholder a substituir etiqueta

  Recomendamos a revisão dos formulários, de forma a garantir que todos os campos possuem etiquetas atribuídas através do elemento . As etiquetas devem estar visíveis junto dos respectivos campos e corretamente associadas, assegurando que os atributos for da etiqueta e id do campo correspondente são iguais.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: As opções dos radio buttons não estão sendo identificados como obrigatório pelas tecnologias de apoio

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.2

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

  No formulário de Rede de Coworking - Sabugal existem opções apresentadas em formato de radio buttons. A escolha de uma destas opções é obrigatória. Quando se navega com um leitor de ecrã, a indicação de que a seleção é obrigatória é anunciada apenas ao aceder ao grupo de opções pela primeira vez. Ao percorrer individualmente cada opção dentro do mesmo grupo, o leitor de ecrã não repete a indicação de obrigatoriedade (necessário):

  

  Quando navega-se com o leitor de ecrã na primeira opção do grupo, é anunciado é obrigatório

  

  Quando navega-se com o leitor de ecrã nas próximas opções do grupo, é anunciado é obrigatório

  

  Quando navega-se com o leitor de ecrã nas opções das checkboxes, ele não anuncia que é obrigatório

  Listamos abaixo formulários que apresentam esse problema e recomendamos reverem de forma geral o website para garantir que campos de seleção radio buttons e checkboxes estejam corretamente construídos. Para isso, cada input deverá conter o atributo required:

  • https://www.cm-sabugal.pt/viver/rede-wifi-gratuita/
  • https://www.cm-sabugal.pt/agenda/festas-da-cidade-s-joao-sabugal-2025/

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem imagens que não possuem um texto alternativo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

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

  Na página Eventos, as imagens ampliadas não possuem texto alternativo preenchido:

  

  Texto alternativo preenchido como nulo ao invés de ter o mesmo texto alternativo que a imagem-link

  Recomendamos rever todas as imagens das páginas de Eventos e Media Center para garantir que tenham o mesmo texto alternativo que a imagem-link com a descrição de que é uma imagem ampliada. Por exemplo, no caso acima o texto alternativo da imagem poderia ser alt="Espetáculo Castelo Setubal (imagem ampliada)"

• evidência: Existem imagens com texto alternativo incorreto

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

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

  Na página Sabugal Presépio 2025, existem imagens com texto alternativo incorreto:

  

  Texto alternativo "Domingao2201 Copiar" é inapropriado

  Recomendamos rever essa imagem para garantir que transmite uma informação útil para o utilizador. Caso optem por defini-la como decorativa é necessário que o texto alternativo seja nulo (alt="").

  ---

  O menu de navegação lateral está apresentando imagens com texto alternativo inapropriado, como por exemplo, na página História está apresentando uma imagem com texto alternativo muito longo e não agrega informação para o utilizador:

  

  Imagem com texto alternativo muito longo e não transmite informação relevante para o utilizador

  Na página Património o menu lateral também apresenta uma imagem com texto alternativo inapropriado:

  

  Imagem com texto alternativo muito longo e não transmite informação relevante para o utilizador

  Recomendamos que revejam as imagens apresentadas no menu lateral, de modo a assegurar que transmitem informação útil para o utilizador. Caso decidam mantê-las apenas como elementos decorativos, é necessário atribuir-lhes um texto alternativo nulo (alt="").

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem mapas sem descrição do conteúdo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.2

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

  Na página Como chegar encontram-se mapas que indicam as direcções para chegar ao Sabugal. No entanto, esta informação é transmitida exclusivamente de forma visual, uma vez que as imagens não dispõem de texto alternativo:

  

  Mapa no formato imagem com texto alternativo nulo

  Recomendamos rever todas as imagens de fluxogramas, gráficos e mapas existentes no website para garantir que tenham um texto alternativo adequado. Para além do preenchimento do atributo alt das imagens, é necessário disponibilizar, na própria página e junto da imagem, um texto descritivo que explique o seu conteúdo. Este texto pode ser associado à imagem através do atributo aria-describedby.

  Para mais informações partilhamos um exemplo de como atribuir texto alternativo em imagens complexas da W3C.

  ---

  Na página Sabugal Presépio 2025, verifica-se que as imagens-links não tem texto alternativo apropriado. Adicionalmente, ao abrir as imagens em modo ampliado, estas não apresentam qualquer descrição em texto que permita aceder ao conteúdo do cronograma do evento, ou seja, utilizadores de leitores de ecrã não terão acesso ao cronograma:

  

  Cronograma apresentado apenas na imagem e não possui descrição em texto

  Recomendamos rever todas as imagens de fluxogramas, gráficos e mapas existentes no website para garantir que tenham um texto alternativo adequado. Para além do preenchimento do atributo alt das imagens-link (é necessário corrigir os apontamentos listados na issue #40), uma das alternativas de correção seria apresentar uma página para cada cronograma, garantindo que a mesma informação seja transmitida em texto.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem imagens-link que não possuem um texto alternativo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

  Na página Sabugal Presépio 2025 e BUPi – Balcão Único do Prédio existem imagens-link que não possuem texto alternativo:

  

  Leitor de ecrã anuncia a url porque não existe um texto alternativo para o link

  

  Imagem-link com texto alternativo alt sem preencher na página Sabugal Presépio 2025

  

  Imagem-link com texto alternativo alt sem preencher na página BUPi – Balcão Único do Prédio

  Recomendamos rever as imagens-link para garantir que todas tenham um texto alternativo preenchido

• evidência: Existem imagens-link que possuem um texto alternativo incorreto

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

  Na página inicial do website é possível verificar que a pesquisa tem o nome atribuído como "Search icon link", o que além de estar em outro idioma, está incorreto:

  

  Nome acessível da pesquisa atribuído como aria-label="Search icon link"

  Recomendamos alterar o nome acessível da pesquisa par ao mesmo idioma do website e que informe claramente o seu significado, como por exemplo: aria-label="Pesquisar".

  ---

  Existem outros locais que apresentam imagens-link com texto alternativo incorreto. Por exemplo, na página Executivo, o texto alternativo das imagens-link inclui o termo “Read:”, o qual não acrescenta informação relevante nem valor de contexto para o utilizador:

  

  Texto alternativo das imagens-link possuem o termo "Read:" que não agrega conteúdo para o utilizador

  Recomendamos que nessas imagens-link seja removido o termo "Read:".

  ---

  Na página do Sabugal Presépio 2025 existem imagens-link com texto alternativo inapropriado, como por exemplo, na secção "Fotos ‘Sabugal Presépio’ 2025" as fotos tem o mesmo nome "Fotos Presépio" sendo diferenciadas apenas pelo número de sequência (1) (2) ... (10):

  

  Imagens com texto alternativo "Fotos Presépio" diferenciadas apenas pela numeração da sequência

  Para além disso, na mesma página é possível identificar outras imagens-links com texto alternativo inapropriado, como por exemplo, imagens nomeadas como "Post Sp 2025" e diferenciadas apenas pela sequência numérica:

  

  Imagens-link com texto alternativo inapropriado

  

  Imagens-link com texto alternativo inapropriado

  Recomendamos a revisão de todas as imagens com link no website, de forma a garantir que o respetivo texto alternativo (atributo alt) é claro, descritivo e comunica corretamente o seu significado.
  Deve ser evitada a utilização de siglas e não devem existir imagens com o texto alternativo preenchido como nulo (alt="").

  Para garantir que as imagens estejam acessíveis, recomendamos que além dessas correções fazerem uma análsie e correção dos pontos levantados na issue #42

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O texto normal não tem contraste suficiente

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 6.1

  No corpo de um documento, o rácio de contraste entre a cor do texto normal (menor que 18 pontos ou menor que 14 pontos negrito) e a cor do fundo é superior a 4,5:1.
  – ver requisito 6.1 na lista 10 aspetos

  Na página Património, existem botões cujo estado :hover apresenta um contraste de 1,6:1, o que está abaixo do recomendado:

  

  Texto do botão com a cor do botão possui contraste abaixo do recomendado (1,6:1)

  Recomendamos rever as seguintes cores para garantir os valores mínimos de contraste do texto normal #005177 com #006FA3.

  ---

  Na página DIA ABERTO | CASTANHEIRO o título do evento tem contraste abaixo do recomendado (2,8:1):

  

  Recomendamos rever as seguintes cores para garantir os valores mínimos de contraste do texto normal #FF6900 com #FFFFFF.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Não existe audiodescrição e legenda no vídeo que contém informações visuais

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 7.2

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

  Na página Bem-vindos ao Sabugal encontra-se um vídeo que não contém áudio narrativo, apenas música de fundo. No entanto, o vídeo destaca pontos específicos da região do Sabugal, sendo essa informação transmitida exclusivamente de forma visual:

  

  Vídeo não possui audiodescrição e legenda

  O mesmo acontece em outros locais, como por exemplo na página Sabugal Presépio 2025:

  

  Para além disso, identificámos vídeos em outras secções do website que apresentam legendas automáticas, as quais não reproduzem de forma fiel o conteúdo falado nos vídeos, como acontece, por exemplo, na página 5 VILAS MEDIEVAIS | 5 Castelos, 5 Histórias:

  

  O texto: "os pés as escavações arqueológicas" é na verdade o texto: "as escavações arqueológicas"

  Recomendamos que seja incluído uma legenda fechada para cada vídeo, caso a legenda gerada automaticamente esteja boa ela pode ser reaproveitada para gerar uma nova transcrição do conteúdo. Os vídeos que não possuem audio, mas visualmente transmitem uma informação para o utilizador devem verificar a necessidade de incluir também uma audiodescrição (como no exemplo da página Bem-vindos ao Sabugal).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem conteúdos que estão visíveis apenas para tecnologias de apoio

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

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

  Quando se retira o CSS na página inicial, é possível identificar o campo de pesquisa do menu compacto que está visível apenas para tecnologias de apoio:

  

  Ao navegar para o próximo elemento a seguir do botão "Subscrever newsletter", o leitor de ecrã identifica o campo de pesquisa que pertence ao menu compacto (tablet, mobile) ao invés de navegar para os elementos do rodapé

  

  Ao desligar CSS é possível identificar o campo de pesquisa do menu compacto

  Recomendamos rever o campo de pesquisa do menu compacto, para garantir que seja visível para as tecnologias de apoio apenas quando ele estiver sendo apresentado visualmente_

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem botões nos carrosséis com nomes acessíveis incorretos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  O botão do primeiro carrossel da página inicial (secção Avisos), que permite suspender a passagem de texto no carrossel, tem o seu nome acessível incorreto.

  

  Botão com o nome acessível “Pause/Play Avisos”

  O texto do botão para pausar o progresso do texto no carrossel é sempre o mesmo, (“Pause/Play Avisos”), independentemente do estado ativado ou desativado de pausa, o que impossibilita aos utilizadores de leitores de ecrã a perceção do estado do carrossel.

  Recomendamos a alteração do texto do botão de pausa, que deve ser diferente dependendo do estado. Por exemplo: “Pause Avisos” quando o texto está em movimento, e “Play Avisos” quando o texto está em pausa.

• evidência: Existem carrosséis estruturados de forma incorreta

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  O carrossel presente na secção “Agenda” da página inicial contém treze eventos iguais.

  

  Carrossel com o mesmo evento repetido treze vezes

  Como se pode observar na figura, o carrossel contém vários itens correspondendo ao mesmo evento. Assim, ao avançar para os próximos eventos do carrossel, nada se altera na visualização.
  Cada elemento <li> contém um aria-label com o valor “1 of 1”, sendo por isso transmitida aos leitores de ecrã a informação de que existe apenas um evento no carrossel, e que o elemento atual é o primeiro, independentemente de qual ele seja.
  Dada esta configuração, um utilizador é levado, por um lado, a pensar que existe apenas um elemento no carrossel. No entanto, como os botões para recuo e avanço na visualização dos slides estão sempre disponíveis, o utilizador pode ir passando pelos elementos do carrossel, sendo que é sempre visualizado o mesmo evento, sem qualquer alteração na visualização e na descrição para os utilizadores de leitores de ecrã.

  Recomendamos que o carrossel seja restruturado para conter apenas os eventos que devem estar disponíveis ao público, sem repetições. Caso, em dado momento, apenas seja necessário disponibilizar um evento, os botões de recuo e avanço devem ser desativados, evitando assim que os utilizadores naveguem pelo carrossel à procura de eventos que não existem, e sem informação sobre o momento em que o carrossel volta aos itens iniciais. Se, por outro lado, for necessário disponibilizar mais do que um evento, os vários eventos devem ter descrições diferentes, e a posição atual e o número total de eventos devem ser transmitidos às tecnologias de apoio, sendo para isso necessário atualizar o atributo aria-label de cada elemento <li> em conformidade (por exemplo, se existirem três eventos, o atributo aria-label do elemento <li> do primeiro evento deve ser “1 de 3”, o segundo deve ser “2 de 3” e o terceiro “3 de 3”).

• evidência: Existem cards estruturados de forma incorreta

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Na página inicial existem cards que não estão estruturados de forma apropriada.

  

  Card estruturado incorretamente

  Os cards presentes na secção “Sabugal” na página inicial têm uma semântica confusa.
  Com efeito, o cabeçalho presente em cada card está rodeado de dois links que remetem para a mesma página: o link que antecede o cabeçalho tem como nome acessível o texto “Infobox Link” num atributo aria-label. Por seu turno, o link que vem a seguir ao cabeçalho tem o mesmo texto do presente no cabeçalho.
  Cada card foi estilizado de modo a ser todo clicável. No entanto, o texto visível para ser clicado é o que está presente em cada cabeçalho, e não o presente em cada link.
  Estruturalmente, o link deve, só por si, desempenhar a sua função, sem elementos auxiliares. Para além disso, cada card não deve conter mais do que um link para o mesmo destino.

  Posto isto, recomendamos que, para cada card nas condições descritas, procedam:

  • À remoção do link cujo aria-label é “Infobox Link”, e que em nada contribui para a compreensão do conteúdo por parte dos utilizadores de leitores de ecrã;
  • À remoção do atributo aria-label do link que tem o mesmo nome acessível do cabeçalho, e à cópia do texto do cabeçalho para dentro do elemento <a>, de modo a que o link tenha o seu texto visível e num único local e que lhe dá o nome acessível (texto visível por todos os utilizadores);
  • À eliminação do cabeçalho de nível 3 (tal como recomendado no issue #77: R 2.2 - 10 Aspetos - Existem cabeçalhos incorretamente atribuídos)
  • À alteração das regras CSS de forma a manter o mesmo aspeto visual do card.

  Para mais informações relativas à construção correta de cards, apenas com o título no link, mas com a restante área do card igualmente clicável, podem consultar o modelo Stretched link do Bootstrap 5.

• evidência: Links consecutivos não estruturados como uma lista ul, li

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Na página Parcerias / Protocolos, existem links dispostos consecutivamente, que não estão estruturados numa lista ul, li.

  

  Links consecutivos na página protocolos não estruturados numa lista ul, li

  Para que os utilizadores de leitores de ecrã obtenham a informação de quantos links se tratam e em que link se encontram, é fundamental que os mesmos sejam estruturados numa lista.
  O mesmo problema ocorre na página Parcerias.
  Recomendamos a estruturação de todos os links que estejam dispostos de forma consecutiva numa lista ul, li.

• evidência: Links do menu Menu lateral incorretamente enriquecidos com o atributo aria-expanded

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Os links do menu lateral que contêm subopções foram incorretamente enriquecidos com o atributo aria-expanded.

  

  Página “Feiras e Mercados” com menu lateral que contém Itens com subopções enriquecidos com o atributo aria-expanded

  Analisando o menu lateral presente na página Feiras e Mercados, percebemos, por exemplo, que a opção “Investimentos” contém duas subopções estruturadas como uma lista. No entanto, se nos mantivermos na mesma página, não é possível aceder à funcionalidade para expandir as subopções. A única forma de serem apresentadas as subopções de “Investimentos” no menu lateral é através do acesso ao link “Investimentos”, que provoca o aparecimento de uma nova página, Investimentos, esta sim já com a lista das subopções de “Investimentos” expandida.

  

  Página investimentos com a lista de subopções visível

  Na nova página, o atributo aria-expanded do link “Investimentos” do menu lateral mantém o valor “false”, apesar de as subopções se encontrarem visíveis, o que é incorreto.

  Conclui-se então que o atributo aria-expanded nos links com subopções presentes no menu lateral induz os utilizadores de leitores de ecrã em erro, que são levados a pensar que conseguirão expandir as subopções desses links, funcionalidade que, como já vimos, não foi implementada.
  Recomendamos a remoção do atributo aria-expanded de todos os links com subopções presentes no menu lateral, de modo a, não só eliminar incoerências entre o valor do atributo e o estado atual das opções, como a proporcionar a mesma experiência de navegação a todos os utilizadores.

• evidência: Existem imagens-link estruturadas de forma inapropriada

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Na página Como chegar existem quatro imagens que, para além de não estarem devidamente estruturadas, não apresentam de um nome acessível. Isso acontece porque está sendo utilizada tags genéricas como divs para representarem imagens interativas:

  

  Leitor de ecrã identifica a imagem-link como "grupo" e não informa o seu nome acessível. As imagens-link estão construídas com divs

  Isso acontece em outros locais do website, nomeadamente na página Capeia Arraiana. Apesar de as imagens-link possuírem texto alternativo, estas estão a ser construídas por divs o que faz com que percam a semântica e não são acessíveis para os leitores de ecrã quando navega por elementos:

  

  Recomendamos rever de modo geral todas as imagens-links e especialmente as que estão sendo apresentadas em Media Center, Contactos e Como chegar.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O foco não está limitado as modais

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.2

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

  Na página de evento Sabugal Presépio 2025, quando selecionamos o botão "Partilhar evento" é aberta uma modal. Embora o foco inicial seja corretamente colocado dentro da modal, é possível aceder a um componente de pesquisa externo com o leitor de ecrã, mesmo com a modal aberta:

  

  Leitor de ecrã identifica um campo de pesquisa com a modal aberta

  Recomendamos que ao utilizar o teclado ou leitor de ecrã, o foco seja limitado apenas para o conteúdo da modal. Enquanto a modal estiver aberta, a navegação por outras opções do website não deve ser possível.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O botão fechar não está acessível pelo leitor de ecrã

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.3

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

  Na modal de pesquisa, o botão "Fechar" está implementado como um elemento . Esta abordagem impede que utilizadores de leitores de ecrã consigam aceder à opção "Fechar" ao navegar pelos elementos da página. Adicionalmente, o botão não está corretamente identificado semanticamente, uma vez que o leitor de ecrã interpreta o elemento como um “grupo”, o que não comunica de forma clara a sua função de botão para fechar a modal:

  

  Leitor de ecrã identifica o "Fechar" como um grupo, ao invés de anunciar como botão "Fechar"

  

  O botão "Fechar" esta estruturado como uma span e não possui nome acessível

  Recomendamos rever o botão de "Fechar” das modais para garantir que estejam corretamente construídos e acessíveis pelo teclado e leitor de ecrã. Para isso, é necessário utilizar elementos nativos do HTML, como o botão (button).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O foco é perdido quando a modal de pesquisa é fechada

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.4

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

  Quando fechamos a modal de pesquisa, o foco do teclado e leitor de ecrã retornam para o link "Ir para o conteúdo":

  

  Foco do teclado retorna para o primeiro link da página

  

  Foco do leitor de ecrã retorna para o primeiro link da página

  Recomendamos que revejam a modal de pesquisa, de forma a garantir que, ao ser fechada, o foco retorne corretamente para o botão de pesquisa.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Não é possível extrair o texto de ficheiros PDF para outro processador de texto

  etiqueta: chk 10 webetiqueta: R 10.1etiqueta: NOK

  Na página Divulgação promocional/turística, ao abrir o ficheiro Mapa Turístico no Acrobat PDF, não é possível extrair o texto para um processador de texto (Word):

  

  Não é possível extrair texto do PDF para o Word

  Isso acontece em outros locais, como por exemplo, no PDF Designação dos membros da mesa de voto antecipado em mobilidade da página Eleições Legislativas 2025:

  

  Ao selecionar o conteúdo do PDF, não é possível extrair o seu conteúdo como texto, ao invés disso aparece uma imagem

  Devem garantir que todos os ficheiros do site em formato PDF possam ser extraídos do Acrobat (CTRL+C e CTRL+V) para um processador de texto (Word), sem haver perda de informação. Desta forma, é possível garantir que o ficheiro PDF pode ser lido por tecnologias de apoio, nomeadamente leitores de ecrã. Recomendamos otimizar todos os ficheiros PDF do website para garantir que sejam extraíveis para um processador de texto.
  No caso de documentos que são fotocópias, contendo apenas imagens, é possível converter os documentos para texto através do Reconhecimento Óptico de Caracteres (OCR) da Adobe.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: R 1.1etiqueta: NOKetiqueta: chk conteúdo

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

  Não existe qualquer resumo do propósito na página inicial do CM Sabugal, pelo que deve ser adicionado:

  

  Não existe um breve resumo sobre o propósito do site CM Sabugal

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

  

  Exemplo de um breve resumo do propósito do website posicionado no topo da página

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: R 1.2etiqueta: NOKetiqueta: chk conteúdo

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

  Não foi encontrado um glossário no website CM de Sabugal, apesar de existirem termos técnicos, como por exemplo, PDM e Rede de Coworking:

  

  Não existe uma descrição para as abreviações PDM, PU , PP, PMDFCI e POM na página Mapas

  

  Não existe uma descrição para a palavra IBERUS na página da notícia Sabugal recebeu Reunião e Fórum do Projeto Transfronteiriço IBERUS

  Recomenda-se a criação de uma página com um glossário que agregue os termos complexos e a sua definição. Pode ser utilizado como referência o glossário do site da Acessibilidade: https://www.acessibilidade.gov.pt/glossario/

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem conteúdos sem data de atualização

  etiqueta: NOKetiqueta: R 1.3etiqueta: chk conteúdo

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

  Foram encontradas páginas sem data de atualização, como por exemplo, a página Mapas - Emissão Plantas | Consulta Planos (Rede Topográfica Municipal) não possui data de atualização do seu conteúdo:

  

  Conteúdo da página não possui data de atualização

  Isso acontece de forma geral no website, como por exemplo, na página Executivo e Contactos:

  

  Conteúdo da página de Executivos não possui data de atualização

  

  Conteúdo da página de Contactos não possui data de atualização

  As datas de atualização não se devem limitar a notícias, pelo que devem ser adicionadas a todas as páginas e/ou blocos de conteúdo do site.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem textos com tamanho de fonte abaixo de 12pt (equivalente a 16px)

  etiqueta: NOKetiqueta: R 2.1etiqueta: chk conteúdo

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

  Na página de Sugestões/Reclamações, o texto "(Obrigatório)" apresenta um tamanho de letra de 13px. Isso acontece também nas instruções de preenchimento que estão posicionadas próximas aos campos, cujo tamanho é de 15px. Por serem informações importantes para o correcto preenchimento do formulário, são por esse motivo consideradas como informação primária:

  

  Texto "(Obrigatório)" com tamanho de fonte abaixo do recomendado (13.008px)

  

  Instrução em texto com tamanho de fonte abaixo do recomendado (15px)

  Na página de Agendas o botão possui tamanho de fonte abaixo do recomendado:

  

  Texto do botão com tamanho abaixo do recomendado (14px)

  Na página Transporte Público de Passageiros existe um link cujo tamanho do texto está abaixo do recomendado:

  

  Texto dos links com tamanho de fonte abaixo do recomendado (12.8px)

  Recomendamos rever de modo geral o website para garantir que o texto dos elementos interativos como botões e links tenham tamanho de fonte de, no mínimo, 16 pixels. Informações que são importantes serem transmitidas para o utilizador e que ajudam a completar uma determinada tarefa, como identificar campos obrigatórios e instruções de como preencher os campos também devem ter um tamanho de fonte de, no mínimo, 16 pixels.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: A informação secundária tem um tamanho de letra inferior a 10pt (equivalente a 13.3px)

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.2

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

  Na página inicial da CM de Sabugal é possível identificar que a data das notícias possuem tamanho de fonte abaixo do recomendado. Isso acontece também na página de Notícias:

  

  Data da notícia com tamanho de fonte de 12.8px na página inicial

  

  Data da notícia com tamanho de fonte de 12.8px na página de Notícias

  Isso acontece em outros locais do website, como por exemplo na página de Boletins e Agendas Municipais, as respectivas datas estão com tamanho de fonte abaixo do recomendado:

  

  Data dos boletins com tamanho de fonte de 12.8px

  No rodapé do website, a informação complementar do custo chamada para a rede fixa nacional e móvel possui tamanho abaixo do recomendado:

  

  Custo chamada para a rede fixa nacional e móvel com tamanho de fonte de 12.8px

  Recomendamos rever de modo geral o website para garantir que a informação secundária tenha um tamanho de fonte de no mínimo 13.3px

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: NOKetiqueta: R 2.3etiqueta: chk conteúdo

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

  Os blocos de texto das páginas de Sortelha e Natural possuem mais de 100 caracteres por linha:

  

  Tamanho do bloco de texto é de 168 caracteres por linha na página Sortelha

  

  Tamanho do bloco de texto é de 168 caracteres por linha na página Natural

  Recomendamos rever de forma geral o website e definir uma largura máxima para as caixas de texto (max-width, em CSS) para garantir que não é ultrapassado o número máximo de caracteres por linha.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O menu principal ultrapassa 9 opções

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 3.1

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

  No menu principal do website, na opção Município → Áreas de Intervenção, existem 10 opções, o que excede o número máximo de opções:

  

  Menu principal com mais de 10 opções

  A mesma situação verifica-se igualmente no menu lateral, bem como nas opções que estão a ser apresentadas na página Áreas de Intervenção:

  

  Menu lateral e opções da página com mais de 10 opções

  Deve ser feita uma revisão da arquitetura de informação do menu de forma a garantir que não ultrapasse 9 opções.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: A posição do menu lateral e do breadcrumb não é igual para todas as páginas do website

  etiqueta: R 3.2etiqueta: chk conteúdoetiqueta: melhoria

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

  Verifica-se uma inconsistência no posicionamento do breadcrumb em algumas páginas do website. Por exemplo, na página Executivo o breadcrumb encontra-se posicionado antes do título principal, enquanto na página Município surge após o título principal:

  

  Breadcrumb posicionado depois do título principal

  

  Breadcrumb posicionado antes do título principal

  Recomendamos que o breadcrumb seja posicionado sempre no mesmo local da página.

  ---

  Verifica-se também uma inconsistência no posicionamento do menu lateral nas páginas do website. Por exemplo, na página Município o menu lateral não é apresentado, já na página História o menu lateral encontra-se visível:

  

  Página não apresenta menu lateral

  

  Página apresenta menu lateral

  Para garantir que o conteúdo seja facilmente lido pelos utilizadores, sem ruído visual ou interações desnecessárias, recomendamos que seja avaliada a real necessidade de utilização de um menu lateral.

  Caso optem por manter o menu lateral, o mesmo deverá seguir uma lógica de consistência em todas as páginas, sendo por isso necessária uma revisão ao nível do website.

  Adicionalmente, é fundamental assegurar que o menu lateral seja acessível. Para tal, deverão também ser corrigidas as observações identificadas na issue #59.

• evidência: O ícone do menu não tem um texto descritivo

  etiqueta: R 3.2etiqueta: chk conteúdoetiqueta: melhoria

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

  O menu nas resoluções mobile e tablet, não possui um texto que indique que o botão é o menu:

  

  Para ser mais claro onde se encontra o menu quando está colapsado (mobile e tablet), recomendamos incluir o texto “Menu” junto ao botão do menu:

  

  Exemplo de como atribuir um texto para evidenciar o menu

• evidência: Não é percetível qual a posição atual do utilizador através do menu principal e breadcrumb

  etiqueta: R 3.2etiqueta: NOKetiqueta: chk conteúdo

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

  No menu principal do website da Câmara Municipal do Sabugal, ao selecionar a opção Balcão Online → Documentos → Câmara Municipal, verifica-se que a posição do utilizador é apresentada visualmente em dois locais distintos, nomeadamente dentro da opção “Município” e do “Balcão Online”, o que pode gerar alguma ambiguidade na navegação.

  Adicionalmente, o breadcrumb não reflete de forma completa o percurso efetuado pelo utilizador, uma vez que deveria apresentar o seguinte caminho: Início → Balcão Online → Documentos → Câmara Municipal.

  

  Posição do utilizador está sendo apresentada em dois locais diferentes, e breadcumb não informa o percurso completo

  Para que o requisito seja cumprido, deve ser garantido que a posição actual do utilizador é evidenciada através de, pelo menos, uma das seguintes opções: menu de navegação ou breadcrumbs.

  No caso do menu, recomenda-se a inclusão de uma sinalética visual adicional à cor para identificar a opção seleccionada. Adicionalmente, deve ser aplicado o atributo aria-current, de forma a assegurar que esta informação é igualmente perceptível pelas tecnologias de apoio.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: As hiperligações não se diferenciam do texto envolvente

  etiqueta: NOKetiqueta: R 3.3etiqueta: chk conteúdo

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

  Existem páginas em que as hiperligações não têm diferenciação suficiente do texto envolvente. Por exemplo, na página Sortelha, é possível identificar o link "aqui" apenas pela cor, pois a frase toda está em negrito:

  

  Link "aqui" destacado apenas pela cor

  Isso acontece de forma geral no website, sendo possível identificar páginas em que existem textos em negrito que não são clicáveis, e o link distinguido apenas pela cor vermelha, como é o caso da página subscrever newsletter:

  

  E-mail da newsletter em negrito mas não é clicável e o link "Política de privacidade" é negrito e perceptível apenas pela cor

  Na página Rede de Coworking - Sabugal existem textos que estão sublinhados e que não funcionam como links:

  

  Uso do sublinhado em textos que não são interativos

  Recomendamos rever o estilo dos links do website para garantir que seja distinguido facilmente entre os conteúdos. Uma possível solução seria diferenciar os links com base na cor e forma (idealmente, colocar sublinhado). O uso do sublinhado em textos normais pode ser associado na identificação de links e por esse motivo, recomendamos evitar o uso do sublinhado em textos normais para garantir também a sua legibilidade.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Não existe um índice no topo de uma página longa

  etiqueta: R 4.1etiqueta: NOKetiqueta: chk conteúdo

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

  Nas páginas consideradas longas, como as páginas Identidade Visual, Política de Privacidade, Termos e Condições de Utilização, Política de Cookies, não existem um índice com hiperligações para cada secção interna dessa página:

  

  Página Identidade Visual com tamanho maior do que 2 ecrãs

  Recomendamos rever as páginas do website para assegurar que, caso tenham mais de dois ecrãs, incluam um índice com hiperligações para cada secção interna.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: R 5.2 - Conteúdo

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.2

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

  Na página inicial, os links das redes sociais e de pesquisa possuem tamanho abaixo do recomendado:

  

  Link facebook com 18px de altura e largura

  

  Link pesquisa com 18.19px de altura e 22px de largura

  Isso acontece em outros locais do website, como por exemplo, o botão fechar da modal de pesquisa:

  

  Botão fechar da modal com 18.19px de altura e 32px de largura

  Devem garantir que os elementos interativos têm uma altura e largura igual ou superior a 44px de área clicável, mesmo que o ícone/imagem tenha um tamanho inferior.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem elementos interativos que aparentam ser clicáveis mas sua área não é clicável

  etiqueta: NOKetiqueta: R 5.4etiqueta: chk conteúdo

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

  Na página inicial, na secção Documentos Online, são apresentados documentos que são clicáveis apenas no seu respectivo texto:

  

  Recomendamos que todo o elemento seja clicável. Como os dois links existentes direcionam para o mesmo destino, o componente pode ser consolidado num único link, alargando a área clicável até aos limites do elemento. Devem garantir também o respectivo contraste com a cor de fundo.

• evidência: Existem elementos interativos que não possuem contraste

  etiqueta: NOKetiqueta: R 5.4etiqueta: chk conteúdo

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

  Na página inicial, os controles do carrossel principal não possuem contraste:

  

  Contraste dos controles do carrossel abaixo do recomendado no estado normal (1,7:1)

  

  Contraste dos controles do carrossel abaixo do recomendado no estado em foco e com transparência (1,8:1)

  

  Controles do carrossel com transparência e constraste abaixo do recomendado

  Isso acontece em outros elementos no website, como por exemplo na página Descobrir, o contorno do botão não possui contraste com a cor de fundo:

  

  Corpo do botão não possui contraste com a cor de fundo (1,1:1)

  Recomendamos a revisão das cores dos vários estados dos elementos para garantir os valores mínimos de contraste em elementos interativos, principalmente nos pares de cores #F1F1F1 com #FFFFFF, cores que sobrepõem imagens e elementos interativos que estão com transparência.

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

  No formulário Rede de Coworking - Sabugal, Sugestões/Reclamações e 'Festas da Cidade – S. João' | 2025, existe um formulário longo onde é pedida toda a informação ao utilizador de uma só vez:

  

  Formulário com mais de 2 ecrãs na página Coworking - Sabugal

  

  Formulário com mais de 2 ecrãs na página Sugestões/Reclamações

  

  Formulário com mais de 2 ecrãs na página 'Festas da Cidade – S. João' | 2025

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

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: Não foi identificado formulários dividos em etapas no website

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

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

  Após verificação constatámos que não existem formulários divididos por etapas no website. Por este motivo o critério passa a ser considerado "Não aplicável".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Não existem restrições do tipo de caracteres nem ao tamanho de preenchimento

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

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

  No formulário de Subscrever Newsletter verificou-se que é possível inserir letras, quando o campo deveria apenas aceitar caracteres numéricos:

  

  Campo telefone aceita caracteres de texto ao invés de permitir apenas caracteres numéricos

  Isso acontece também nos formulários de 'Festas da Cidade – S. João' | 2025 e Rede de Coworking - Sabugal.

  Recomendamos que os campos de formulário sejam revistos e se limite o tipo de caracteres que é possível inserir, consoante o tipo de campo. Devem rever especialmente os formulários que tenham os campos de telefone, NIF e Código Postal. É necessário garantir que existe um limite máximo de caracteres nos campos mencionados.

• evidência: O tamanho do campo telefone e email não refletem o tamanho previsível dos dados

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

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

  No formulário de Subscrever Newsletter, os campos de "telefone" e "email" são muito grandes para a informação inserida, dando a entender que se pode escrever mais:

  

  Os campos de preenchimento de telefone e email são muito grandes para a informação a ser preenchida

  O mesmo acontece no formulário de 'Festas da Cidade – S. João' | 2025, onde os campos de "telefone" e "10-B. Dimensões da Banca ou Extrutura Própria (frente x profundidade x altura em cm)" são demasiados grandes para o seu preenchimento:

  

  Os campos de preenchimento de telefone e 10-B. Dimensões da Banca ou Extrutura Própria (frente x profundidade x altura em cm) são muito grandes para a informação a ser preenchida

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

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: Não existem campos dependentes de outros campos durante preenchimento

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

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

  Verifica-se que os formulários do website não possuem campos que são apresentados consoante ao preenchimento de outro campo. Por esse motivo, o critério passa a ser considerado como "Não aplicável".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem campos do formulário cuja legenda não é clara ou é repetitiva

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

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

  No formulário da Rede de Coworking - Sabugal, a legenda "Nome" encontra-se associada a um único campo igualmente denominado "Nome". Esta duplicação gera redundância, tornando a legenda desnecessária:

  

  Legenda com o mesmo nome que a etiqueta do campo

  Recomendamos a remoção da legenda, uma vez que esta agrupa apenas um único campo.

  ---

  No formulário de Subscrever Boletins e Agendas Municipais, a legenda apresenta o mesmo nome que a etiqueta "Endereço". Contudo, uma vez que a legenda agrupa vários campos de preenchimento, é essencial que o seu nome seja claro e informe sobre o que é para preencher:

  

  Legenda Endereço não descreve o tipo de informação a ser agrupada a preenchida nos campos

  Recomendamos alterar o nome da legenda para algo parecido com "Morada" para informar que os campos correspondem ao mesmo tipo de preenchimento, que no caso é morada.

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

  No formulário de Subscrever Boletins e Agendas Municipais, o termo de privacidade é apresentado como uma checkbox de seleção obrigatória, assinalada através de um asterisco (*). No entanto, o formulário não esclarece o significado do asterisco e adicionalmente, a forma como esta obrigatoriedade é comunicada ao utilizador revela-se inadequada, uma vez que a interação não fornece uma informação clara sobre o seu significado:

  

  _ O texto "Tem de aceitar nesta caixa" não informa o significado do asterísco de forma assertiva_

  Recomendamos adicionar uma legenda no início do formulário que indique claramente o significado do asterísco (*).

  ---

  Na página Subscrever Newsletter, os campos cujo placeholder inclui um asterisco (*) utilizam essa marca como a única sinalética visual que indica que o seu preenchimento é obrigatório:

  

  Placeholder com sinalética visual (*) para indicar campos de preenchimento obrigatório

  Recomendamos adicionar uma legenda no início do formulário que indique claramente o significado do asterísco (*). Outra alternativa seria incluir o texto (Obrigatório) tal como está sendo feito nos demais formulários do website.

• evidência: Existem campos obrigatórios que não estão sendo identificados visualmente

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

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

  No formulário de Rede de Coworking - Sabugal, os campos de Endereço, Localidade e Código Postal são obrigatórios e não estão sendo sinalizados como tal. Essa informação está sendo transmitida pelo fieldset o que não é recomendado:

  

  Campos Endereço, Localidade e Código Postal não possuem o texto "(Obrigatório)" assim como os demais campos de preenchimento obrigatório

  Isso acontece em outros locais no website, como por exemplo, no formulário de Subscrever Boletins e Agendas Municipais:

  

  Campos Primeiro, Último, Inserir o email, Confirmar email, Endereço, Endereço Linha 2, Cidade, Código postal e País não possuem o texto "(Obrigatório)" assim como os demais campos de preenchimento obrigatório

  A indicação de que um campo é de preenchimento obrigatório deve ser apresentada em cada campo individualmente e não no fieldset a que pertence. Recomendamos a revisão dos formulários do website, de forma a garantir que todos os campos obrigatórios incluem essa informação de forma explícita, através da sinalética visual que já é utilizada (“Obrigatório”).

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: Não existem ações consideradas destrutivas no website

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

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

  Não identificamos ações consideradas destrutivas, como exclusão, cancelamento ou alteração de dados pessoais no website. Por isso, esse critério é considerado como "Não aplicável".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Não são devolvidas mensagens de erro junto a cada campo do formulário

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

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

  No formulário de Rede de Coworking - Sabugal está sendo apresentado uma única mensagem de erro para os campos Endereço, Código Postal e Localidade. Para além disso, visualmente é possível identificar os campos com problema apenas pela cor:

  

  Uma única mensagem de erro está sendo apresentada para 3 campos diferentes Endereço, Código Postal e Localidade

  Isso acontece também nos seguintes formulários:

  • https://www.cm-sabugal.pt/subscrever-boletins-e-agendas-municipais/
  • https://www.cm-sabugal.pt/agenda/festas-da-cidade-s-joao-sabugal-2025/

  Recomendamos que seja apresentado uma mensagem de erro para cada campo. A mensagem deverá estar próxima ao respectivo campo.

  ---

  No formulário de Subscrever Boletins e Agendas Municipais é possível identificar que as mensagens de erro estão com o mesmo espaçamento que os próprios campos. Os campos que possuem instruções é mais nítido esse espaço podendo gerar dúvidas sobre qual campo é a mensagem de erro:

  

  Espaçamento distante do respectivo campo

  Recomendamos que seja revisto o espaçamento da mensagem de erro, de modo a que fique visualmente evidente a que campo se refere. Uma possível solução seria apresentar a instrução imediatamente após a etiqueta do campo e colocar a mensagem de erro logo abaixo do mesmo, com um espaçamento mais próximo, reforçando visualmente a associação entre o campo e a respetiva mensagem de erro.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Não existem mensagens de erro em campos preenchidos de forma inapropriada

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

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

  No formulário de Rede de Coworking - Sabugal não existe mensagem de erro quando o campo de telefone e código postal são preenchidos de forma inapropriada:

  

  Campo telefone e código postal não possui mensagem de erro

  Recomendamos rever os formulários que tenham os campos NIF, Código postal, telefone e email, para garantir que as mensagens de erro devolvidas junto aos campos sejam úteis na resolução do problema e identifiquem os passos necessários para o resolver. Devem indicar qual o formato correto de preenchimento. Por exemplo, no campo do código postal, colocar “Insira um código de postal válido (ex: (0000-000).”

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

Lista de evidências recolhidas:

• evidência: Outras violações - Existem botões num idioma diferente do configurado no site

  etiqueta: outras violaçõesetiqueta: melhoria

  Os botões dos carrosséis existentes na página inicial têm o seu texto em inglês.

  

  Botões de pausa, retrocesso e avanço nos slides de um dos carrosséis, cujos textos estão em inglês

  Recomendamos que o texto de todos os controlos seja apresentado no idioma do site.

• evidência: Outras violações - Existem vídeos iniciados automaticamente

  etiqueta: outras violaçõesetiqueta: melhoria

  O vídeo apresentado na página Bem-vindos ao Sabugal está sendo iniciado automaticamente assim que o utilizador acede á página, o que não é recomendado:

  

  Recomendamos que os vídeos do website sejam configurados para iniciar apenas quando o utilizador os ativar através dos controlos.