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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #50 Está sendo utilizado atributos que mudam a semântica da lista

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.1

  O menu principal e o menu lateral estão a ser estruturados como listas, utilizando as tags ul e li do HTML. No entanto, está também a ser aplicado o atributo role="group.

  A utilização deste atributo altera a semântica originalmente definida no HTML, fazendo com que estes elementos sejam interpretados de forma semelhante a um fieldset, o que não é adequado no contexto de menus de navegação:

  

  Subopções do menu principal contém o atributo role="group"

  URL a verificar

  • https://cm-felgueiras.pt/ - menu principal

  Sugestão de correção

  • Remover o atributo role="group" de todas as opções do menu.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

  Quando selecionamos uma opção que contém subopções, não é possível voltar a fechá-la para continuar a navegar pelas outras opções do menu. Isso acontece no menu compacto e no desktop.

  Por exemplo, ao selecionar a opção “Município” com o leitor de ecrã, as subopções são corretamente apresentadas no menu. No entanto, quando tentamos fechar novamente a opção “Município” para aceder a outras opções do menu, ocorre o carregamento da página “Município” e o menu é automaticamente fechado.

  Isso acontece porque estão a ser atribuídas duas funções ao mesmo elemento: por um lado, ele é utilizado para apresentar as subopções do menu; por outro, é também o elemento responsável por aceder à página “Município”:

  

  Opção "Município" fechada

  

  Opção "Município" aberta

  

  Quando selecionamos novamente "Município" a página Município é carregada e o menu se fecha automaticamente

  URL a verificar

  • https://cm-felgueiras.pt/ - menu principal compacto e desktop

  Sugestão de correção

  • Devem verificar no menu compacto e desktop.
  • O mesmo elemento é utilizado simultaneamente para expandir/contrair subopções e para aceder à página “Município”, o que provoca erros de navegação. Por esse motivo, devem separar o link de navegação da página "Município" e do botão para abrir/fechar as subopções.
  • O elemento que abre e fecha as subopções deve ser um botão ▾ com o atributo aria-expanded. Caso optem em utilizar a sinalética ▾ para o botão, devem garantir que tenha um nome acessível apropriado, como por exemplo: "Abrir subopção de Município".
  • O acesso à página “Município” deve ser feito através de um link a.
  • Para mais informações partilhamos um exemplo de menu flyout da W3C: https://www.w3.org/WAI/tutorials/menus/flyout/#use-button-as-toggle

• evidência: issue #64 Não é possível diferenciar as navegações do website

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

  Com o leitor de ecrã, são identificadas três áreas de navegação: a do menu principal e duas no rodapé, ambas anunciadas com o nome “Menu”. Esta repetição impede o utilizador de distinguir qual navegação é do menu principal e quais correspondem às secções do rodapé:

  

  URL a verificar

  • https://cm-felgueiras.pt/ - menu principal e rodapé

  Sugestão de correção

  • No rodapé, a lista "Sistema de Gestão da Qualidade" também deve ser estruturada como um elemento nav, totalizando três áreas de navegação no rodapé.
  • No rodapé, é necessário atribuir nomes distintos às três navegações para que seja possível diferencia-las corretamente. Como alternativa, podem utilizar o título de cada secção como valor do atributo aria-label, por exemplo:
    • <nav aria-label="Sistema de Gestão da Qualidade">
    • <nav aria-label="Ligações úteis">
    • <nav aria-label="Contactos">

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

  O atributo aria-haspopup deve ser utilizado apenas em conjunto com os atributos role="menuitem", role="menu" ou role="menubar" na construção de menus do tipo aplicação. No entanto, o menu principal deste website corresponde a um menu de navegação e não a um menu de aplicação. Por esse motivo, não é apropriado utilizarem esse atributo no menu:

  

  Para além disso, embora as subopções do menu estejam estruturadas com elementos ul e li, estas não preservam a semântica própria de uma lista, uma vez que estão a ser agrupadas através do atributo role="group". Esta abordagem não é recomendada, pois altera a semântica nativa dos elementos e compromete a leitura da informação pelos leitores de ecrã, que deixam de reconhecer as opções como uma lista e, consequentemente, não informam o número de itens disponíveis:

  

  URL a verificar

  • https://cm-felgueiras.pt/ - menu principal do website

  Sugestão de correção

  • Devem alterar no menu compacto e no desktop.
  • Remover os atributos aria-haspopup e role="group" do menu principal.
  • Utilizar o atributo aria-expanded para gerenciar a abertura e fecho das opções do menu.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #66 O texto alternativo das opções do menu lateral está inapropriado

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.3

  A sinalética visual “▾” apresentada no menu lateral possui o texto alternativo em inglês "Close menu section":

  

  Verifica‑se também que o botão ▴ / ▾ está a ser estruturado dentro de um link, o que não é recomendável, pois gera problemas de interação ao colocar elementos interativos dentro de outro elemento interativo. Por exemplo, quando se navega com a tecla TAB, o leitor de ecrã anuncia o nome do link e o botão como se fossem um único elemento interativo, apesar de desempenharem funções distintas:

  

  Link "Cidadania e inclusão" e botão "Open menu section"

  URL a verificar

  • Todas as páginas que apresentam o menu lateral.
  • https://cm-felgueiras.pt/viver/desporto-e-lazer/

  Sugestão de correção

  • O texto alternativo deve ser apresentado em português e descrever de forma clara a ação que o botão executa. Por exemplo: “Abrir subopções de Esporte e Lazer” ou “Fechar subopções de Esporte e Lazer”, consoante o estado do botão (utilizar aria-expanded).
  • Separar estruturalmente o link de navegação do botão de abrir/fechar subopções.

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

Lista de evidências recolhidas:

• evidência: issue #37 Correta existência de títulos h1 no website

  etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 2.1

  O website apresenta corretamente títulos h1, no entanto, na página inicial o logótipo está sendo atribuído ao título "Site do Município de Felgueiras". O título está abaixo do banner principal da página:

  

  URL a verificar

  • https://cm-felgueiras.pt

  Sugestão de correção

  • O elemento H1 deve ser atribuído ao logótipo do website, exclusivamente na página inicial. Nas restantes páginas internas, o H1 deve manter-se associado ao título principal de cada página, sem alterações.
  • Após esta alteração na página inicial, o actual h1 "Site do Município de Felgueiras" deve ser removido ou alterado para h2.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #38 Incorreta marcação hierarquizada de títulos e subtítulos

  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

  Nas páginas referidas existem saltos de cabeçalhos (por ex: h2 seguido de um h4), e também títulos que não estão marcados como cabeçalhos:

  

  Figura 1 - Formulário de "Apresentação de Reclamação" com salto na hierarquia de cabeçalhos do h2 para o h4. Deve ser removido o header "RECLAMANTE" e "RECLAMADO".

  

  Figura 2 - Evidência de salto de h2 para h4 com a ferramenta Web Developer. Url: https://cm-felgueiras.pt/servicos/informacao-e-apoio-ao-consumidor/#gf_7

  

  Figura 3 - Evidência de salto de h2 para h4 com a ferramenta Web Developer. Url: https://cm-felgueiras.pt/municipio/prestacao-de-contas/

  

  Figura 4 - Título "Pedido de informação" não marcado como cabeçalho.

  

  Figura 5 - "CONTACTOS" e "LOCALIZAÇÃO" e " Notícias relacionadas" não estão marcados como cabeçalhos.

  

  Figura 6 - Títulos do acordeão marcados como span, deviam ser marcados como cabeçalhos.

  

  Figura 7 - Títulos do acordeão marcados como span, deviam ser marcados como cabeçalhos.

  URLs a verificar:

  https://cm-felgueiras.pt/servicos/informacao-e-apoio-ao-consumidor/
  https://cm-felgueiras.pt/municipio/prestacao-de-contas/
  https://cm-felgueiras.pt/
  https://cm-felgueiras.pt/municipio/imprensa/noticias/
  https://cm-felgueiras.pt/category/obras-municipais/
  https://cm-felgueiras.pt/viver/protecao-civil/
  https://cm-felgueiras.pt/servicos/balcao-de-servicos/ - título do formulário "Pedido de Informação"
  https://cm-felgueiras.pt/venha-experimentar-saborear-e-sentir-felgueiras/ - títulos "CONTACTOS" e "LOCALIZAÇÃO" e " Notícias relacionadas" não estão estruturados como cabeçalhos (necessário rever todo o website)
  https://cm-felgueiras.pt/municipio/projetos-cofinanciados/ - acordeões (necessário rever todo o website)

  Recomendação de melhoria:

  • Na página de Informação e Apoio ao Consumidor devem remover os cabeçalhos h4 "RECLAMANTE" e "RECLAMADO" do formulário "Apresentação de Reclamação" para corrigir o salto entre cabeçalhos e remover a redundância entre os títulos, uma vez que já apresentam o título "Dados do Reclamante" e "Dados do Reclamado"como h2.
  • Devem rever todos os acordeões apresentados no website para garantir que seus respectivos títulos sejam cabeçalhos. No exemplo mencionado, é necessário alterar os títulos dos acordeões para headers h3. Na estrutura o h3 deve ser posicionado fora do botão, ou seja, ele deve conter o botão. Dessa forma garantimos que não seja perdida a sua semântica.
  • Nas páginas cujo títulos representam cards de notícias, eventos e programação, o título deve ser estruturado como h3 (necessário garantir a hierarquia de cabeçalhos).
  • Alterar os h4 para h3, quando não existe um h3 presente na página. Mantendo uma sempre uma hierarquia na página h1 -> h2 -> h3 -> h4.
  • Verificar títulos semelhantes aos mencionados acima e estrutura-los como cabeçalhos. Por exemplo, o título "Pedido de Informação" pode ser alterado para h2.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

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

  A etiqueta “Autenticação” do formulário da página Inquérito de Satisfação – Qualidade está associada a um elemento <div>:

  

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

• evidência: issue #67 Existem caixas de verificação, botões de rádio e caixas de texto não envolvidos em elementos `<fieldset>`

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

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

  Os grupos de botões de rádio do formulário na página Inquérito de Satisfação de Qualidade não estão envolvidos em elementos <fieldset>:

  

  Etiqueta incorretamente aplicada ao grupo de botões de rádio
  Como se pode observar na figura, os botões de rádio “Insatisfeito”, “Parcialmente Satisfeito”, “Satisfeito” e “Muito Satisfeito” estão associadas à legenda “Tempo de decisão/resposta(Obrigatório)”. No entanto, essa associação não existe semanticamente.
  Para que tal aconteça, os botões de rádio devem ser colocadas dentro de um elemento <fieldset>, elemento esse que deve ter como primeiro filho um elemento <legend> contendo o texto “Tempo de decisão/resposta(Obrigatório)”, da seguinte forma:

  <fieldset>
    <legend>Tempo de decisão/resposta(Obrigatório)</legend>
    <input id = " rb1 " type = "radio">
    <label for = "rb1"> Insatisfeito</label>
    <input id = " rb2 " type = "radio">
    <label for = "rb2">Parcialmente Satisfeito</label>
  </fieldset>
  

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

  que é a razão de ser do agrupamento de botões de rádio, transmitindo assim um maior contexto acerca da função destes campos.
  Fazemos notar que, tal como está, o elemento com o texto “Tempo de decisão/resposta” não tem utilidade, pois não está associado semanticamente a nenhum campo.
  O mesmo problema acontece nos agrupamentos “Clareza da Informação Recebida(Obrigatório)” e “Funcionamento do Serviço Prestado(Obrigatório)” do mesmo formulário.
  O agrupamento “Morada” do formulário da página Informação e Apoio ao Consumidor também deve ser restruturado conforme indicações supra.
  Recomendamos que agrupamentos de botões de rádio e de caixas de verificação sejam colocados dentro de elementos <fieldset>, e os elementos <label> de catalogação de cada grupo devem ser substituídos por elementos <legend> colocados dentro do elemento <fieldset>, conforme apresentado acima.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #72 Não é possível identificar campos obrigatórios com o leitor de ecrã

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.2

  Existem campos de formulários que o leitor de ecrã não identifica como sendo de preenchimento obrigatório. Por exemplo, na página de Informação e Apoio ao Consumidor, o campo de upload de ficheiro “Documento Complementar” não está programaticamente definido como obrigatório:

  

  Não está sendo utilizado o atributo aria-required ou o required

  Outro exemplo ocorre na página de Inquérito de Satisfação – Qualidade, onde os radio buttons não estão programaticamente definidos como obrigatórios:

  

  URLs a verificar

  • https://cm-felgueiras.pt/servicos/informacao-e-apoio-ao-consumidor/#gf_7
  • https://cm-felgueiras.pt/servicos/sistema-gestao-da-qualidade/inquerito-de-satisfacao-qualidade/

  Sugestão de correção

  • Para garantir que leitores de ecrã anunciam corretamente a obrigatoriedade do campo, deve ser utilizado o atributo nativo required do HTML ou, o atributo aria-required.

• evidência: issue #70 Formulários PDFs não indicam campos obrigatórios

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.2

  Verifica‑se que alguns formulários estão a ser disponibilizados no formato PDF. Embora seja tecnicamente possível tornar formulários em PDF acessíveis, isso exige um trabalho específico e cuidadoso — como definição de etiquetas, ordem de leitura, campos de formulário corretamente identificados e indicação de obrigatoriedade. Um PDF não se torna acessível de forma automática apenas por conter campos editáveis.

  Nos formulários PDF disponibilizados no website da CM Felgueiras, não é possível identificar quais os campos de preenchimento obrigatório, tanto visualmente como através do leitor de ecrã:

  

  URL a verificar

  • Necessário verificar todos os formulários em PDF do website
  • https://cm-felgueiras.pt/discussao-publica-da-proposta-de-2-a-alteracao-a-1-a-revisao-do-plano-diretor-municipal/#2622-2622-wpfd-top

  Recomendação de melhoria

  • Construir formulários utilizando elementos HTML e apresenta-los no website. Dessa forma garantimos que o seu preenchimento seja acessível para um maior número de pessoas, incluindo pessoas com necessidades especiais.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #73 O leitor de ecrã não identifica as mensagens de erro

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.3

  No formulário de Apresentação de Reclamação, as mensagens de erro são apresentadas no topo do formulário. Para além de não estarem associadas programaticamente aos respetivos campos, verifica‑se um segundo problema.

  O formulário está dividido em duas etapas:

  1. Dados do reclamante
  2. Dados do reclamado

  Quando o utilizador submete o formulário com erros, todas as mensagens de erro são exibidas no topo da primeira etapa, incluindo erros relativos a campos que pertencem à etapa 2, para além do formulário do topo não direcionar o utilizador para os campos da etapa 02, as mensagens de erro deixam de estar visíveis na etapa 02 pois elas não estão associadas ao campo, impedindo a identificação dos campos incorretos:

  

  Mensagens de erro das etapas 01 e 02 apresentadas no topo do formulário

  

  Na etapa 02, não é possível identificar os campos com erro

  URL a verificar

  • https://cm-felgueiras.pt/servicos/informacao-e-apoio-ao-consumidor/#gf_7

  Sugestão de correção

  • As mensagens de erro devem ser apresentadas junto ao respetivo campo e posicionadas imediatamente após o campo.
  • Idealmente elas devem estar associadas ao seu respectivo campo.

• evidência: issue #71 Formulários PDFs não apresentam mensagens de erro

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.3

  Verifica‑se que alguns formulários estão a ser disponibilizados no formato PDF. Embora seja tecnicamente possível tornar formulários em PDF acessíveis, isso exige um trabalho específico e cuidadoso — como definição de etiquetas, ordem de leitura, campos de formulário corretamente identificados e indicação de obrigatoriedade. Um PDF não se torna acessível de forma automática apenas por conter campos editáveis.

  Os formulários PDF do website da CM Felgueiras que foram avaliados, não transmitem mensagens de erro programaticamente e visualmente:

  

  URL a verificar

  • Necessário verificar todos os formulários em PDF do website
  • https://cm-felgueiras.pt/discussao-publica-da-proposta-de-2-a-alteracao-a-1-a-revisao-do-plano-diretor-municipal/#2622-2622-wpfd-top

  Recomendação de melhoria

  • Construir formulários utilizando elementos HTML e apresenta-los no website. Dessa forma garantimos que o seu preenchimento seja acessível para um maior número de pessoas, incluindo pessoas com necessidades especiais.
  • Devem garantir que as mensagens de erro sejam claras e que ajudem o utilizador durante o seu preenchimento.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #17 (Melhoria) Imagens decorativas com texto alternativo inapropriado

  etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 5.1

  Verifica-se que as imagens presentes nos cards da secção de notícias não acrescentam informação relevante ou adicional ao conteúdo textual já disponibilizado (título e descrição da notícia). No entanto, estas imagens estão a ser expostas aos leitores de ecrã através de texto alternativo preenchido, o que pode introduzir redundância na navegação.

  Neste contexto, as imagens devem ser tratadas como decorativas, devendo possuir alt="" para garantir que não são anunciadas pelas tecnologias de apoio.

  

  URL a verificar

  (necessário rever todos os cards apresentados no website)
  https://cm-felgueiras.pt/municipio/imprensa/noticias/
  https://cm-felgueiras.pt/villa-romana-de-sendim-ultrapassa-os-mil-visitantes-em-2025/#jp-carousel-156618

  Sugestão de correção

  • Imagens decorativas devem ter alt="".

• evidência: issue #10 Imagens não decorativas com texto alternativo incorreto ou inexistente

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

  Verificado que imagens não decorativas possuem atributo alt vazio. Estas imagens possuem valor informativo, uma vez que ilustram atividades, espaços e interações descritas no conteúdo da página. A ausência de descrição textual impede que utilizadores de tecnologias de apoio compreendam o conteúdo visual apresentado.

  

  URL a verificar

  (deve ser verificado em todo site)
  https://cm-felgueiras.pt/villa-romana-de-sendim-ultrapassa-os-mil-visitantes-em-2025/
  https://cm-felgueiras.pt/felgueiras-iluminada-de-vermelho-para-sensibilizar-para-os-cancros-do-sangue/
  https://cm-felgueiras.pt/cerimonia-de-abertura-do-museu-casa-do-assento/
  https://cm-felgueiras.pt/aqui-ha-gato-e-boas-historias-tambem-com-sofia-vieira-num-dia-dedicado-aos-afetos/

  Sugestão de correção

  As imagens não decorativas deverão ter uma descrição breve associada, nomeadamente através do uso do atributo alt descrevendo corretamente a imagem apresentada. Por exemplo: alt="Grupo de visitantes a observar ruínas arqueológicas"

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #11 Imagem/gráfico não é acompanhada de uma descrição longa

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.2

  Foi identificado que a imagem complexa presente na página não é acompanhado por uma descrição longa que transmita a informação apresentada visualmente. O conteúdo disponibiliza uma representação visual dos dados, sem alternativa textual equivalente, o que impede utilizadores de tecnologias de apoio de compreenderem a informação.

  

  URL a verificar

  https://cm-felgueiras.pt/externato-de-unhao-recebe-etapa-decisiva-do-campeonato-felgueiras-xadrez/

  Sugestão de correção

  • A informação pode ser apresentada diretamente no conteúdo da página juntamente com o texto existente, ou associada à imagem através de mecanismos como aria-describedby.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #48 Existem imagens-link e botões que estão sendo estruturados de forma inapropriada

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

  As imagens da galeria encontram-se associadas a elementos com role="button" e aria-label genérico (“Open image in full-screen”), não existindo uma associação clara entre o conteúdo visual e um nome acessível significativo.

  Adicionalmente, esta abordagem pode originar redundância ou ambiguidade na leitura por tecnologias de apoio, uma vez que o elemento interativo não está corretamente estruturado como link com conteúdo associado.

  Para além disso, verifica-se que as imagens da galeria são apresentadas como elementos interativos (role="button" / link) para abertura em ecrã completo, no entanto, a sua implementação não segue a estrutura semântica adequada para imagens com função de link.

  

  ---

  Outro exemplo pode ser observado na página inicial. Visualmente, é possível perceber que as imagens-link funcionam como um único elemento interativo, composto pela área clicável, título e imagem. No entanto, a nível estrutural, estes elementos encontram-se separados. Como consequência, os leitores de ecrã anunciam cada parte de forma independente, não interpretando o conjunto como um único elemento — neste caso, uma imagem-link:

  

  Visualmente distingue-se 6 imagens-link, o "Serviços municipais" é uma dessas opções

  

  Estruturalmente o elementos que fazem parte do link "Serviços municipais" estão separados: é possível identificar a imagem, o texto "Serviços municipais" e o link (a) que está vazio

  

  Leitor de ecrã identifica o link "Serviços municipais"

  

  Leitor de ecrã identifica o texto "Serviços municipais"

  URL a verificar

  (verificar em todo o website)
  https://cm-felgueiras.pt/viver/cultura/centro-interpretativo-villa-romana-de-sendim/#conteudo-108430-info
  https://cm-felgueiras.pt/viver/cultura/centro-interpretativo-villa-romana-de-sendim/#conteudo-108430-info
  https://cm-felgueiras.pt/fim-de-semana-gastronomico-de-felgueiras-2026-27-a-29-de-marco/
  https://cm-felgueiras.pt/felgueiras-promove-o-concelho-na-fitur-2026-uma-das-maiores-feiras-internacionais-de-turismo/

  Sugestão de correção

  • Se possível, remover elementos adicionais (role, tabindex e aria-label) e passar a informação direto na imagem.
  • Cada imagem interativa seja envolvida por um elemento semântico adequado (<a> ou <button>, conforme a ação).
  • A imagem associada tenha alt="" quando não acrescenta informação adicional ou é acompanhada por um texto visível.
  • No exemplo da página inicial, o link deve conter a imagem e o texto visível.

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

  A imagem link na sessão "Obras municipais" apresenta um texto alternativo incorreto através do atributo alt. Por exemplo, apresenta a descrição "cemi1" ao navegar pela imagem. Este texto não descreve corretamente a ação ou destino do link.

  

  Figura 1 - Imagem link com descrição no atributo alt incorreto

  

  Figura 2 - Imagem link apresenta descrição incorreta durante a navegação com leitor de ecrã

  Outro exemplo é a imagem link para voltar para a Homepage que referencia o logotipo e não a ação ou destino do link. Uma alternativa de texto seria: alt="Página inicial da Camara Municipal de Felgueiras".

  

  Figura 3 - Imagem link homepage com descrição no atributo alt incorreto

  

  Figura 4 - Descrição no incorreta, apresenta title="unnamed"

  Verifica-se que alguns componentes de texto associados a links podem gerar ambiguidade na compreensão da ação a executar. Como o exemplo da imagem onde apresenta o texto: title="Abrir página: IEFP - abre numa nova janela".

  

  https://cm-felgueiras.pt/investir/apoio-ao-investidor-empresario/

  URL a verificar

  https://cm-felgueiras.pt/
  https://cm-felgueiras.pt/investir/apoio-ao-investidor-empresario/
  https://cm-felgueiras.pt/municipio/freguesias/
  https://cm-felgueiras.pt/municipio/concelho-de-felgueiras/contactos-uteis/

  Sugestão de correção

  • A descrição deve transmitir claramente o destino ou finalidade do link.
  • Recomenda-se ajustar o conteúdo textual para evitar ambiguidade, como por exemplo: "IEFP abre numa nova janela" ou "Página IEFP - abre numa nova janela."

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #49 Incorreto rácio de contraste na a cor dos textos de tamanho normal

  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

  Utilizando o website em darkmode, existem várias conteúdos onde o rácio de contraste não está correto.

  

  Figura 1 - O texto da tabela assinalado na imagem não tem o minimo rácio de contraste entre texto e cor de fundo (4,5:1).

  

  Figura 2 - O texto da tabela assinalado na imagem não tem o minimo rácio de contraste entre texto e cor de fundo (4,5:1) .

  Para além disso, em determinadas situações, verifica-se um funcionamento incorreto da janela de cookies quando esta não é fechada. Ao carregar uma nova página, o fundo da janela desaparece, tornando o texto ilegível devido ao baixo contraste com o fundo:

  

  Figura 3 - A janela de aceitar as cookies perdeu a cor de fundo, não tendo suficiente contraste com o conteudo presente.

  URLs a verificar:

  https://cm-felgueiras.pt/viver/educacao/acao-social-escolar/#conteudo-146988-info

  https://cm-felgueiras.pt/viver/cultura/centro-interpretativo-villa-romana-de-sendim/

  Recomendação de melhoria:

  Corrigir as cores do texto nas tabelas, de forma a que respeitem o o mínimo rácio de contraste entre texto e cor de fundo (4,5:1).

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

Lista de evidências recolhidas:

• evidência: issue #60 Foi possivel ativar os botões de controlo do leitor quer com o rato quer com o teclado

  etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 7.1

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

  Verifica-se que não é possível interagir de forma adequada com os controlos do vídeo. Por exemplo, ao iniciar a reprodução, os controlos ficam ocultos e, para os tornar novamente visíveis, é necessário ativar uma opção localizada no canto do vídeo. A identificação dessa opção só é possível com o indicador de foco do navegador. Com o teclado, não é apresentada qualquer informação visível que permita compreender a sua função. Esta situação não é recomendada, uma vez que o utilizador pode não perceber que se trata de um elemento que permite aceder aos controlos do vídeo.

  Evidências:

  

  Recomendações:

  É necessário garantir que os controles do vídeo apresentem um ícone ou texto visível da sua função, além do indicador de foco visível, assegurando que o utilizador consegue identificar claramente a ação disponível.

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

Lista de evidências recolhidas:

• evidência: issue #69 As legendas do player não são audiodescritivas

  etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 7.2

  Apesar do vídeo ter legendas não automáticas e até disponíveis em várias línguas, alguns elementos visuais não são descritos nas legendas, como por exemplo, a descrição dos vinhos demonstrados, os locais turísticos, a arte.

  

  URL a verificar:

  • https://cm-felgueiras.pt/venha-experimentar-saborear-e-sentir-felgueiras/

  Recomendações:

  Incluir uma audiodescrição para que as pessoas cegas ou com visão parcial tenham acesso as informações transmitidas pelo vídeo visualmente, como a descrição dos vinhos, os locais da região de Felgueiras, etc...

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

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

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

  

  URL a verificar

  • https://cm-felgueiras.pt/ - campo de pesquisa

  Sugestão de correção

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

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Notas Gerais

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

  URL a verificar

  • https://cm-felgueiras.pt/
  • https://cm-felgueiras.pt/plano-de-pormenor-do-alto-das-barrancas/ (todas as notícias)

  Evidências:

  O componente de feedback está estruturado como um conjunto de botões (<button>) dentro de um contentor com role="group", sendo utilizado o atributo aria-pressed para indicar o estado selecionado.

  No entanto, este padrão corresponde semanticamente a um conjunto de botões de alternância (toggle buttons), quando na realidade o comportamento implementado permite apenas uma única seleção, semelhante a um grupo de botões de rádio.

  Adicionalmente:

  • Não é utilizado o elemento semântico input type="radio".
  • As opções não estão sendo construídas com uma label associada.
  • O estado selecionado não é comunicado através de aria-checked, mas sim através de aria-pressed, o que não é adequado neste contexto;
  • Não existe suporte explícito para navegação por teclado com setas (comportamento esperado em radio groups).

  

  Figura 1 – Componente de feedback implementado com botões e aria-pressed

  Recomendações:

  Recomenda-se que o componente seja implementado de acordo com o padrão de grupo de botões de rádio (radio group), garantindo uma interpretação correta por tecnologias de apoio. Para isso, devem utilizar elementos nativos <input type="radio">, que já incorporam comportamento acessível por defeito junto com outros elementos, como o form e label (devendo o input estar associado a label pelo id e for).

  Recomenda-se ainda validação com leitores de ecrã e navegação por teclado para garantir conformidade com as boas práticas de acessibilidade.

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Notas Gerais

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

  URL a verificar

  • https://cm-felgueiras.pt/ (pesquisa)
  • https://cm-felgueiras.pt/servicos/balcao-de-servicos/ (enviar mensagem)
  • https://cm-felgueiras.pt/servicos/informacao-e-apoio-ao-consumidor/ (enviar mensagem)
  • https://cm-felgueiras.pt/fim-de-semana-gastronomico-de-felgueiras-2026-27-a-29-de-marco/#jp-carousel-159897

  Evidências:

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

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

  

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

  Recomendações:

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

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

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

• evidência: issue #55 Elementos interativos estruturados como `<div>` no controlo de fechar do carousel/modal

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Notas Gerais

  • Elementos interativos como botões devem ser implementados com elementos HTML semânticos apropriados, como <button>, de forma a garantir que são corretamente interpretados por tecnologias de apoio e suportam navegação por teclado.

  URL a verificar

  • https://cm-felgueiras.pt/fim-de-semana-gastronomico-de-felgueiras-2026-27-a-29-de-marco/#jp-carousel-159898

  Evidências:

  No componente de carousel de imagens, o botão de fechar o modal é implementado através de um elemento <div class="jp-carousel-close-hint"> que contém um ícone SVG, sem utilização de um elemento nativo interativo como <button>. Apesar de existirem outros controlos no carousel com role="button", também recomendamos utilizar sempre que possível o elemento nativo do HTML, pois já incorporam o comportamento acessível por defeito.

  

  Figura 1 – Controlo de fechar do carousel implementado como <div> em vez de <button>

  Recomendações:

  Recomenda-se substituir o elemento div por um elemento semântico <button>, garantindo que o controlo de fechar o modal é corretamente identificado como elemento interativo pelas tecnologias de apoio.

  Deve ser assegurado que o botão mantém todas as funcionalidades existentes, incluindo foco por teclado, ativação por Enter/Espaço e comunicação adequada do estado quando aplicável. Recomenda-se ainda validação com leitores de ecrã e navegação por teclado para garantir conformidade com boas práticas de acessibilidade.

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Notas Gerais

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

  URL a verificar

  • https://cm-felgueiras.pt/municipio/imprensa/noticias/
  • https://cm-felgueiras.pt/category/obras-municipais/
  • https://cm-felgueiras.pt/

  Evidências:

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

  

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

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

  Recomendações:

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

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

• evidência: issue #42 Existem acordeões estruturados incorretamente

  etiqueta: melhoriaetiqueta: 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

  Notas Gerais

  • Um acordeão é um conjunto de cabeçalhos interativos empilhados verticalmente, cada um contendo um título e uma secção do conteúdo. Os títulos funcionam como controlos que permitem aos utilizadores revelar ou ocultar as secções de conteúdo associadas. Os acordeões são normalmente utilizados para reduzir a necessidade de deslocação ao apresentar várias secções de conteúdo numa única página.
  • A utilização de elementos genéricos como <span> ou <div> com atributos ARIA para simular botões (role="button") não garante, por si só, um comportamento acessível, podendo comprometer a navegação e a perceção do componente.

  Evidências:

  Na página Centro Interpretativo Villa Romana de Sendim, existem componentes interativos que funcionam como acordeões ou elementos expansíveis, mas que são implementados com elementos não semânticos.

  Verifica-se a utilização de elementos <span> com role="button" e tabindex="0" para simular comportamento interativo

  

  Figura 1 – Acordeão implementado com <span> e role="button"

  Esta abordagem obriga à simulação manual de comportamentos nativos, como foco, ativação por teclado (Enter e Espaço) e anúncio do estado do componente, não garantindo consistência entre diferentes navegadores e tecnologias de apoio.

  Como consequência, utilizadores de leitores de ecrã ou que navegam por teclado podem não conseguir perceber corretamente que o elemento é interativo, nem o seu estado (expandido ou recolhido), podendo também ocorrer falhas na ativação do componente.

  Recomendações:

  • Deve ser verificado em todo o website.
  • Os elementos interativos que funcionam como controlos de expansão devem ser implementados com elementos nativos do HTML, nomeadamente <button>, evitando o uso de elementos genéricos como <span> ou <div> com role="button".
  • A utilização de <button> garante automaticamente suporte para navegação por teclado, ativação com teclas padrão (Enter e Espaço) e correta interpretação por tecnologias de apoio.
  • Deve ser assegurado que o estado do componente é comunicado através do atributo aria-expanded, corretamente atualizado em função da interação do utilizador, e que existe associação programática com o conteúdo controlado através de aria-controls.
  • Recomenda-se ainda a validação com teclado e leitores de ecrã para garantir que o componente é corretamente identificado, operável e compreensível em diferentes contextos de utilização.

• evidência: issue #41 Elementos agrupados visualmente sem estrutura semântica adequada

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Evidências:
  Em várias secções do sítio Web, existem conjuntos de elementos apresentados visualmente como grupos relacionados, mas que não possuem uma estrutura semântica adequada no código.

  Na secção de “Ligações úteis”, as hiperligações são apresentadas como um conjunto de opções, mas sem qualquer estrutura que permita identificar que pertencem a uma lista.

  

  Figura 1 – Ligações úteis apresentadas como grupo visual sem estrutura semântica

  Na secção de “Destaques Home”, os documentos (ficheiros PDF) surgem como uma listagem de conteúdos, mas estão implementados com elementos genéricos, sem indicação de lista.

  

  Figura 2 – Documentos apresentados como conjunto, mas sem estrutura de lista

  Adicionalmente, os blocos de navegação da página inicial (ex.: “Serviços Municipais”, “Cidadania e Inclusão”, entre outros) são apresentados como cartões clicáveis, mas não são semanticamente identificados como um conjunto de opções de navegação.

  

  Figura 3 – Cartões de navegação apresentados sem estrutura semântica clara

  Quando os estilos CSS são desativados, estes elementos passam a ser apresentados como conteúdos isolados, sem indicação da relação entre si, dificultando a perceção da estrutura da página.

  Recomendações:

  • Deve ser verificado em todo o site.
  • Os conjuntos de conteúdos que representem listas (ex.: ligações úteis, documentos, opções de navegação) devem ser marcados semanticamente como listas.
  • Conteúdos do mesmo tipo e apresentados em grupo devem utilizar elementos apropriados de lista, garantindo que cada item é identificado como parte de um conjunto.
  • Evitar a utilização exclusiva de elementos genéricos para representar agrupamentos de informação.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.1

  Verifica-se que a modal não é totalmente acessível para navegação por teclado e tecnologias de apoio. Ao ser aberta, o foco não é automaticamente direcionado para o seu conteúdo, permanecendo fora do contexto da modal. Este comportamento impede a interação imediata com o componente e compromete a sua utilização por utilizadores de teclado e leitores de ecrã.

  

  URL a verificar

  https://cm-felgueiras.pt/villa-romana-de-sendim-ultrapassa-os-mil-visitantes-em-2025/#jp-carousel-156618

  Sugestão de correção

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #25 Foco não esta limitado a modal

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.2

  Ao navegar com leitor de ecrã dentro da modal, o foco retorna para elementos da página subjacente (ex: Município), em vez de permanecer limitada ao conteúdo da modal.

  

  URL a verificar

  https://cm-felgueiras.pt/

  Sugestão de correção

  • Garantir que a navegação por teclado fica limitada ao seu conteúdo da modal até seu encerramento.

  • Mesmo os elementos interativos (links, botões ou campos de edição) apresentados fora da modal devem deixar de ser focáveis quer com teclado quer com o rato quando a modal esta aberta.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #52 Não é possível fechar a modal com o teclado ou leitor de ecrã

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.3

  Verificado que ao abrir a modal de pesquisa o foco esta a ser posicionado no campo de pesquisa ao invés de posicionar no primeiro elemento que é o botão fechar. Recomenda-se que o foco seja direcionado para o primeiro elemento que é o botão fechar.

  

  Verifica-se também que o carrossel em modo de visualização ampliada (overlay) não cumpre os requisitos de acessibilidade relativos à navegação por teclado. Apesar de assumir o comportamento de uma modal (sobreposição do conteúdo), o componente não implementa corretamente os mecanismos necessários para garantir uma navegação acessível. Não é possível fechar a modal com o teclado ou leitor de ecrã:

  

  URL a verificar

  https://cm-felgueiras.pt/villa-romana-de-sendim-ultrapassa-os-mil-visitantes-em-2025/
  https://cm-felgueiras.pt/viver/cultura/centro-interpretativo-villa-romana-de-sendim/

  Sugestão de correção

  • Deve ser possível sair ou fechar a modal, quer através de teclado quer através de um dispositivo apontador.
  • Recomenda-se que o foco seja direcionado para o primeiro elemento ao aceder a modal.

• evidência: issue #27 Modais não podem ser encerradas através da tecla ESC

  etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 9.3

  Verifica-se que janelas modais que não podem ser encerradas com a tecla ESC, o que limita a interação por teclado e compromete a usabilidade para utilizadores de tecnologias de apoio.

  

  URL a verificar

  https://cm-felgueiras.pt/

  Sugestão de correção

  • Recomenda-se a implementação de um mecanismo que permita o encerramento das janelas modais através da tecla ESC, garantindo uma interação consistente e acessível para utilizadores de teclado.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #29 Ao fechar a modal o foco não é devolvido para o elemento que o acionou

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.4

  Utilizando o leitor de ecrã ou navegação por teclado - ao fechar a janela modal "Gerir o Consentimento", o foco não é devolvido ao elemento que a acionou (botão “Gerir Consentimento”). Em vez disso, o foco perde-se ou é reposicionado de forma inconsistente, prejudicando a navegação.

  

  Verificado que a modal de galeria possui implementação inadequada e gestão de foco incorreta, o foco não retorna ao elemento acionador.

  

  URL a verificar

  https://cm-felgueiras.pt/
  https://cm-felgueiras.pt/villa-romana-de-sendim-ultrapassa-os-mil-visitantes-em-2025/#jp-carousel-156620

  Sugestão de correção

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

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 10.1

  Não é possível extrair o conteúdo do PDF para um formato txt. Para além disso, não é possível descarregar ficheiros PDF através de teclado ou leitor de ecrã, devido à ausência de foco e/ou interação acessível com o elemento de download, isso impossibilita que utilizadores que dependem exclusivamente de navegação por teclado ou leitores de ecrã consigam efetuar o download do documento.

  

  URL a verificar:

  https://cm-felgueiras.pt/servicos/sistema-gestao-da-qualidade/#flipbook-df_156738/4/

  Recomendação:

  • Deve permitir o download de ficheiros PDF através de navegação por teclado e tecnologias de apoio, garantindo que o elemento é focável e acionável.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #8 Verificação de resumo na página inicial.

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.1

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

  Boas práticas:

  O propósito de um website é diferente da missão ou objetivo de uma instituição. A página inicial deve incluir uma breve descrição das principais funcionalidades disponíveis no website.

  Descrição do Problema:

  Verificou-se que a descrição do propósito do website ("Sítio Oficial da Câmara Municipal de Felgueiras") não resume fielmente quais as tarefas ou a informação que é possível encontrar (ver Figura 01).

  

  Figura 1: Imagem com o resumo incompleto no topo esquerdo.

  Recomendações

  Recomenda-se que a descrição do propósito seja alterada para representar mais fielmente a finalidade do site e a informação que contém, tal como se verifica no exemplo do site acessibilidade.gov.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 1.2

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

  Evidências:

  Apesar da existência de um glossário, este encontra-se incompleto, uma vez que ainda subsistem diversos termos técnicos e palavras complexas sem definição. Em seguida encontram-se apenas alguns exemplos encontrados pelo site:

  

  Imagem com o termo complexo abordagem intersectorial, disponível em: https://cm-felgueiras.pt/viver/estrategia-municipal-de-saude/

  

  Imagem com as Siglas sem definição agregada UMAR e GNR, disponível em: https://cm-felgueiras.pt/viver/coesao-e-acao-social/humanamente-iguais/

  

  Imagem com o termo complexo "CAE" sem definição agregada, disponível em: https://cm-felgueiras.pt/viver/contratacao-publica/

  

  Imagem de um formulário com o termo complexo "CAE" sem definição agregada, disponível em: https://cm-felgueiras.pt/discussao-publica-da-proposta-de-2-a-alteracao-a-1-a-revisao-do-plano-diretor-municipal/#2622-2622-wpfd-top (Formulário PDF “Formulário - alt2_rev1_pdm”)

  Recomendações:
  Recomenda-se a revisão e expansão do glossário existente, assegurando a inclusão de todos os termos técnicos ou complexos presentes nos conteúdos do website. Sempre que esses termos forem utilizados, devem estar acompanhados de definições claras ou ligações diretas para o respetivo glossário, promovendo assim a compreensão e acessibilidade da informação para todos os utilizadores.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.1

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

  O website possui informações primárias com tamanho inferior a 12pontos(16px). Por exemplo, é o corpo de texto da modal de cookies, com conteúdo informativo com dimensão inferior ao recomendado. (Figura 1)

  

  Figura 1 - Verificação do tamanho do texto da modal de cookies

  O mesmo acontece no corpo de texto da página Política de Cookies.

  Outro exemplo na página inicial, são os textos dos botões do “Questionário de avaliação” com dimensão de 13.3px. (Figura 2)

  

  Figura 2 - Verificação do tamanho do texto de botões com tamanho inferior ao recomendado.

  O mesmo acontece nas páginas:

  • https://cm-felgueiras.pt/felgueiras-reconhecida-pelas-boas-praticas-em-beneficio-dos-cuidadores-informais/
  • https://cm-felgueiras.pt/projeto-de-regulamento-do-conselho-municipal-das-pessoas-com-deficiencia/

  Recomendação de melhoria
  É necessário ser corrigido os textos de informações primárias, para um tamanho igual ou superior ao recomendado. Para garantir a legibilidade do corpo de texto, este deve ter um tamanho igual ou superior a 12pt, que equivale a 16px.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #20 Excesso de opções no subnível do menu de navegação

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.1

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

  Evidências:
  O menu de navegação principal inclui um subnível com 12 opções disponíveis, ultrapassando o número recomendado para uma navegação clara e eficiente. Este excesso de escolhas pode dificultar a compreensão da estrutura do website, aumentar a carga cognitiva dos utilizadores e tornar a localização de conteúdos mais lenta e confusa.

  

  Imagem do subnível da navegação principal com 12 opções.

  Nota:

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

  Atualmente, verifica-se que este limite é ultrapassado em alguns casos, nomeadamente nas seguintes páginas:

  • https://cm-felgueiras.pt/servicos/sistema-gestao-da-qualidade/
  • https://cm-felgueiras.pt/viver/coesao-e-acao-social/
  • https://cm-felgueiras.pt/municipio/assembleia-municipal/

  Adicionalmente, como exemplo, no subnível da secção “Ação Social”, o número de opções também excede o recomendado, dificultando a navegação e a compreensão da estrutura do conteúdo.

  

  Imagem do menu secundário "Viver" com o subnível "Ação Social" aberto.

  Recomendações:

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

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

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

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

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

  • Considerar a introdução de sub-subníveis ou menus progressivos (ex.: “ver mais”) para distribuir melhor as opções.

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

Lista de evidências recolhidas:

• evidência: issue #21 Navegação principal está sempre visível e sempre no mesmo local

  etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: R 3.2

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

  O menu de navegação principal aparece sempre no topo da página em todo o domínio.

  

  Figura 1: Imagem do menu principal do domínio.

  Notas de melhoria:

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

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

  Verificou-se que as opções do menu principal "Proteção Civil" e "Presidenciais" surgem também no menu secundário, respetivamente dentro das opções "Viver" e "Município".

  

  Figura 2: Imagem da opção do menu principal "Proteção Civil" no subnível da opção "Viver"

  

  Figura 3: Imagem da opção do menu principal "Presidenciais" no subnível da opção "Município"

  Opções dos menus com títulos diferentes nas páginas:

  A opção "Investir", ao ser selecionada, apresenta uma página com o título "Investimento Empresarial". Esta diferença de nomenclatura pode causar confusão, conforme ilustrado na figura 4.

  

  Figura 4: Imagem da página "Investir" com o título "Investimento Empresarial"

  A página "Áreas de Acolhimento Empresarial" surge no menu secundário com o título "Aceder à Plataforma N-Invest". Na figura 5 é possível observar esta diferença.

  

  Figura 5: Imagem da página "Áreas de Acolhimento Empresarial" com título diferente no menu secundário.

  A página "Visitar" apresenta como título "Venha experimentar, saborear e sentir… Felgueiras!", o que também não corresponde diretamente à designação do menu.

  

  Figura 6: Imagem da página "Visitar" com o título "Venha experimentar, saborear e sentir… Felgueiras!"

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

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

  • https://cm-felgueiras.pt/municipio/
  • https://cm-felgueiras.pt/viver/
  • https://cm-felgueiras.pt/servicos/

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

  • https://cm-felgueiras.pt/municipio/presidenciais-2026/
  • https://cm-felgueiras.pt/viver/protecao-civil/

  Por fim, a opção do menu secundário "Visitar" não apresenta nem menu secundário nem organização em blocos.

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

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

  Na figura 7 é possível observar que a organização dos dois menus é bastante diferente. Por exemplo, "Breve História do Concelho" aparece como segundo nível no menu principal, enquanto no menu secundário surge como terceiro nível, estando incluído dentro de "Concelho de Felgueiras".

  Além disso, a opção "Prestação de Contas" está presente no menu secundário, mas não existe no menu principal.

  

  Recomendações:

  Recomenda-se a revisão do menu secundário de forma a alinhá-lo com o menu principal e com a estrutura das páginas. É também importante garantir consistência na organização e nomenclatura dos menus ao longo de todo o website, tornando a navegação mais clara, intuitiva e acessível para todos os utilizadores, especialmente num site com múltiplos níveis e rotas.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 3.3

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

  Evidências:

  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:

  1. Nas modais associadas ao botão “Enviar mensagem” para os vereadores, o link “política de privacidade” não apresenta sublinhado, sendo distinguido apenas pela cor.

  

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

  Páginas onde ocorre o problema:

  • https://cm-felgueiras.pt/viver/servicos-urbanos/documentos/
  • https://cm-felgueiras.pt/servicos/concessoes-administrativas/
  • https://cm-felgueiras.pt/viver/gestao-urbanistica/

  2. No rodapé do website, os links “Ver âmbito do certificado” e “Inquérito de satisfação” só são identificáveis como links quando o utilizador passa o rato (hover), não sendo visualmente distintos no estado normal.

  

  Imagem com os links no rodapé sem estar sublinhados.

  3. Nas páginas do website que contêm donwloads de pdfs, os links do título do pdf só são identificáveis como links quando o utilizador passa o rato (hover), não sendo visualmente distintos no estado normal.

  

  Imagem de um título de pdf clicável sem indicação visual.

  Recomendação:

  Garantir que todos os links:

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

  • Incluam sublinhado ou outro indicador visual consistente;

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #31 Melhoria na usabilidade de acordeões em páginas com conteúdo extenso para leitores de ecrã

  etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: R 4.1

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

  Ponto 01
  Sugestão de melhoria
  Página: https://cm-felgueiras.pt/servicos/sistema-gestao-da-qualidade/

  Verifica-se que, em alguns casos, a estrutura de conteúdos longos é apresentada através de componentes em formato de acordeão, o que permite reduzir a extensão vertical da página. Nestes casos, a validação do requisito passa também pela correta acessibilidade destes componentes, nomeadamente a sua navegação através de teclado e compatibilidade com tecnologias assistivas, como leitores de ecrã.

  A página Sistema Gestão da Qualidade utiliza acordeões para organizar conteúdo extenso, o que ajuda na navegação visual e reduz o scroll. No entanto, ao navegar com leitor de ecrã, a estrutura pode tornar a experiência um pouco repetitiva, já que o conteúdo é anunciado de forma sequencial dentro dos componentes, o que pode tornar a leitura menos fluida.

  

  Recomendação:
  Rever a estrutura dos acordeões do ponto de vista de acessibilidade, de forma a melhorar a experiência com leitores de ecrã, reduzindo repetições desnecessárias e garantindo uma navegação mais fluida e eficiente para utilizadores de tecnologias assistivas.

• evidência: issue #28 Ausência de índice em página com conteúdo extenso

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 4.1

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

  Ponto 01

  Notas Gerais:

  • Para facilitar a navegação em páginas longas, com várias secções de conteúdos, deve existir um índice no topo da página. Esse índice deve conter hiperligações para as várias seções que existem.

  Foram analisadas páginas com conteúdo extenso em versão desktop, considerando a presença de páginas com altura superior a três ecrãs (referência 1024px ou equivalente). Por exemplo na página da notícia HISTORIC RALLY FAFE: Duas dezenas de “relíquias” para dar espetáculo na terra em Felgueiras (Figura 01)

  

  Figura 1 - Exemplo de página longa sem índice no topo

  Exemplo de páginas analisadas com conteúdo extenso:

  • https://cm-felgueiras.pt/investir/
  • https://cm-felgueiras.pt/viver/coesao-e-acao-social/humanamente-iguais/
  • https://cm-felgueiras.pt/viver/protecao-civil/#2023-2022-wpfd-boletim-informativo

  Recomendações
  Adicionar um índice com hiperligações para cada secção interna, e garantir que o índice tem hiperligações que remetem para o conteúdo corretamente com a navegação.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #4 Inconsistências de alinhamento em componentes de questionário em mobile

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 4.2

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

  Ponto 01
  Página: https://cm-felgueiras.pt/

  Em dispositivos móveis, as opções do questionário de satisfação não ficam todas alinhadas de forma consistente. Em alguns casos, os itens aparecem desalinhados entre si, o que deixa a apresentação menos uniforme e pode afetar a leitura das opções.
  Adicionalmente, verifica-se que o conteúdo envolvente (elementos anteriores e seguintes) não se adapta corretamente ao ecrã em mobile, apresentando-se parcialmente cortado em alguns pontos, o que compromete a legibilidade e a experiência de utilização.

  Exemplo encontrado também noutras partes do website:
  https://cm-felgueiras.pt/projeto-da-1-a-alteracao-do-regulamento-felgueiras-acessivel-empresas-inicio-de-procedimento/
  https://cm-felgueiras.pt/projeto-da-1-a-alteracao-do-regulamento-felgueiras-acessivel-empresas-inicio-de-procedimento/

  Recomendação:
  Recomenda-se ajustar o comportamento responsivo destes elementos, garantindo alinhamento consistente das opções e assegurando que nenhum conteúdo é cortado em diferentes tamanhos de ecrã.

  

  O print abaixo demonstra que o conteúdo anterior e seguinte encontra-se cortado em ecrãs móveis, não se adaptando corretamente ao tamanho do dispositivo.

  

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

  Em dispositivos móveis, o carrossel da página inicial não é apresentado, resultando numa inconsistência de conteúdo e funcionalidade entre versões desktop e mobile. Esta situação não assegura a adaptação consistente do layout a diferentes tamanhos de ecrã, podendo levar à perda de informação para utilizadores mobile.

  Exemplo adicional:
  https://cm-felgueiras.pt/projeto-da-1-a-alteracao-do-regulamento-felgueiras-acessivel-empresas-inicio-de-procedimento/

  Verifica-se comportamento semelhante, com elementos de navegação/funcionalidade que não são apresentados de forma consistente em dispositivos móveis.
  Recomendação:
  Deve ser garantido que todos os componentes interativos e informativos, incluindo o carrossel da página inicial, sejam totalmente responsivos e mantidos em todos os dispositivos (desktop, tablet e mobile), sem perda de conteúdo ou funcionalidade.

  

  Ponto 03
  Página : https://cm-felgueiras.pt/municipio/freguesias/

  Os elementos interativos do mapa cumprem a dimensão mínima recomendada de 44px CSS, assegurando teoricamente a área de interação adequada.
  No entanto, em dispositivos móveis, verifica-se um desalinhamento dos elementos, com posições sobrepostas ou desorganizadas em determinados ecrãs, o que dificulta a interação precisa com os mesmos.
  Esta situação não está relacionada com o tamanho dos elementos, mas sim com a sua distribuição e alinhamento no layout responsivo, comprometendo a usabilidade em dispositivos de toque.

  Recomendação:
  Deve ser garantida a correta disposição e alinhamento dos elementos interativos no mapa em todos os tamanhos de ecrã, assegurando:

  • espaçamento adequado entre pontos interativos
  • prevenção de sobreposição de elementos
  • ajuste responsivo da distribuição dos ícones
  • validação em diferentes resoluções de dispositivos móveis

  Estas melhorias devem assegurar que, além de cumprir o tamanho mínimo recomendado, os elementos sejam facilmente selecionáveis e visualmente organizados.

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #6 Tamanho insuficiente e inconsistências de interação em elementos clicáveis

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.2

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

  Ponto 01
  Página: https://cm-felgueiras.pt/viver/educacao/

  O checkbox associado à opção “Li e aceito a política de privacidade” apresenta dimensão reduzida (aprox. 13px), abaixo do mínimo recomendado de área clicável

  Recomendação:
  Recomenda-se aumentar a área clicável, garantindo um mínimo de 44x44px, de forma a melhorar a acessibilidade e a interação em dispositivos móveis.

  

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

  Os elementos de seleção do grau de satisfação (emojis) apresentam dimensão inferior ao mínimo recomendado de área clicável.

  Exemplo adicional:
  https://cm-felgueiras.pt/projeto-da-1-a-alteracao-do-regulamento-felgueiras-acessivel-empresas-inicio-de-procedimento/

  Recomendação:
  Recomenda-se aumentar a área clicável para um mínimo de 44x44px, garantindo melhor usabilidade.

  

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

  Os elementos interativos do carrossel em “Notícias relacionadas”, incluindo setas de navegação, apresentam área clicável inferior a 44x44px.

  Recomendação:
  Recomenda-se aumentar a área clicável dos controlos do carrossel para o mínimo recomendado de 44x44px.

  

  Ponto 04

  Verifica-se que a modal de cookies apresenta diversos elementos interativos com dimensão inferior ao mínimo recomendado de 44x44px, comprometendo a acessibilidade e a facilidade de interação, especialmente em dispositivos móveis.

  Estão incluídos:

  • Botão de fechar da modal
  • Checkbox de seleção de preferências
  • Setas de navegação nas opções em formato acordeão

  Recomendação:
  Recomenda-se aumentar a área clicável dos elementos interativos presentes na modal de cookies, garantindo um mínimo de 44x44px.

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #5 Existem múltiplos botões de ação principal com o mesmo destaque visual na mesma página

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.3

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

  Ponto 01
  Página: https://cm-felgueiras.pt/venha-experimentar-saborear-e-sentir-felgueiras/

  Foi identificado que na página existem múltiplas ações apresentadas com o mesmo nível de destaque visual, o que pode gerar ambiguidade na tomada de decisão do utilizador.

  Como resultado, o utilizador é exposto a várias opções com o mesmo peso visual, o que pode tornar a experiência menos clara e induzir dúvida sobre qual a ação principal a executar.

  Adicionalmente, verifica-se que dentro dos próprios componentes (cards), os elementos interativos apresentam o mesmo estilo visual, sem distinção entre ações principais e secundárias, reforçando a ausência de hierarquia.

  Recomendação:
  Recomenda-se garantir a existência de apenas um botão de ação principal por página, devidamente destacado através de uma cor contrastante e maior hierarquia visual.

  Todos os restantes botões devem ser tratados como ações secundárias, com menor destaque visual.

  

  Ponto 02
  Página: https://cm-felgueiras.pt/servicos/informacao-e-apoio-ao-consumidor/#gf_7

  No formulário identificado, os elementos interativos “Anexar ficheiro”, “Anterior” e “Enviar mensagem” apresentam o mesmo estilo visual, não existindo distinção clara entre ação principal e ações secundárias.

  Recomendação:
  Recomenda-se garantir uma hierarquia visual clara entre ações de formulários, assegurando que a ação principal (submissão) se destaca face às restantes.

  

  Ponto 03

  O botão de ação “Voltar” não possui destaque visual suficiente nem aparenta ser um elemento clicável. A sua apresentação aproxima-se de texto simples, sem diferenciação clara ao nível de cor, estilo ou componente visual.
  Esta situação compromete a identificação da ação disponível, podendo causar dificuldade na navegação, especialmente para utilizadores com menor literacia digital ou baixa visão.

  Acontece nas páginas:
  https://cm-felgueiras.pt/servicos/regulamentos-e-posturas/#322-338-wpfd-posturas
  https://cm-felgueiras.pt/servicos/regulamentos-e-posturas/#322-336-wpfd-taxas-municipais
  https://cm-felgueiras.pt/servicos/regulamentos-e-posturas/#322-324-wpfd-regulamentos-internos
  https://cm-felgueiras.pt/servicos/regulamentos-e-posturas/#322-583-wpfd-projetos-de-regulamentos

  Recomendação:
  Reforçar o estilo visual do botão “Voltar”, garantindo que é claramente identificável como elemento interativo (ex: uso de cor de fundo, borda, ícone ou contraste adequado).
  Assegurar consistência com outros botões do site (ex: estilo de botão primário/secundário).
  Garantir estados de hover e focus visíveis, reforçando a perceção de interatividade.

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #7 Falta de consistência e indicação visual de interatividade em elementos gráficos e componentes clicáveis

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

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

  Ponto 01
  Página: https://cm-felgueiras.pt/
  Os elementos de seleção do grau de satisfação (emojis), apesar de serem interativos, apresentam um contraste reduzido face ao fundo, o que compromete a sua visibilidade.
  Verifica-se uma situação semelhante em elementos de navegação em modo dark, nomeadamente nas setas de interação, que também apresentam baixo contraste (aprox. 1.26:1), afetando a sua legibilidade.

  Esta situação dificulta a perceção destes elementos enquanto opções interativas, não sendo suficientemente evidentes do ponto de vista visual.

  Exemplo adicional:
  https://cm-felgueiras.pt/servicos/regulamentos-e-posturas/
  https://cm-felgueiras.pt/municipio/

  Recomendação:
  Deve ser garantido que todos os elementos interativos (como emojis de avaliação e setas de navegação) apresentem um contraste adequado face ao fundo, de forma a assegurar a sua legibilidade e identificação clara enquanto elementos clicáveis.

  

  Ponto 02
  Página : https://cm-felgueiras.pt/
  Foram identificados elementos gráficos clicáveis (imagens) que não apresentam qualquer indicação visual de que são interativos no estado inicial. A perceção de que se trata de um elemento acionável apenas ocorre mediante interação (passagem do rato ou navegação por teclado com foco ativo).

  Recomendação:
  Garantir que elementos gráficos interativos possuem indicação visual clara de interatividade, através de estilos como destaque, sombra, contorno ou outros indicadores visuais consistentes com elementos clicáveis.

  

  Ponto 03
  Página:
  https://cm-felgueiras.pt/municipio/freguesias/

  No mapa interativo presente na página, os elementos gráficos (ícones tipo “radar”) são interativos, permitindo a abertura de um card informativo com a opção “Saber mais”.
  No entanto, estes elementos não apresentam qualquer indicação visual clara de que são clicáveis, não sendo percetíveis como elementos interativos à primeira vista. A sua aparência é semelhante a elementos estáticos/decorativos, o que dificulta a descoberta da funcionalidade por parte do utilizador.
  Adicionalmente, não existe reforço visual de interatividade (ex: hover, destaque, sombra ou alteração de cor), o que compromete a affordance do componente.

  Recomendação:
  Deve ser garantido que todos os elementos gráficos interativos do mapa sejam facilmente identificáveis como clicáveis, através de reforços visuais consistentes,

  

  Ponto 04
  Em todas as páginas do web site

  O botão “Gerir consentimento”, presente no banner de cookies, apresenta um estilo visual neutro no estado inicial, com fundo branco e sem indicadores claros de interatividade.
  A perceção de que o elemento é clicável só se torna evidente ao passar o rato (hover), através da aplicação de sombra. Este comportamento não é suficiente para garantir a identificação imediata da funcionalidade, especialmente em dispositivos móveis ou contextos sem interação por hover.
  Adicionalmente, em modo dark, mantém-se a ausência de elementos visuais que reforcem a sua natureza interativa, o que compromete a consistência da affordance entre temas.

  Recomendação:
  Recomenda-se reforçar a aparência do botão “Gerir consentimento” no estado inicial, de forma a torná-lo imediatamente reconhecível como elemento interativo.

  Sugere-se:

  • introdução de contorno ou contraste mais evidente no estado default
  • utilização de estilos consistentes de botão (não apenas aparência de texto neutro)
  • reforço visual em dark mode para manter legibilidade e destaque
  • garantir estados de hover e focus consistentes e acessíveis

  Estas melhorias devem assegurar que a interatividade seja perceptível sem necessidade de interação prévia.

  

  Ponto 05
  Página: https://cm-felgueiras.pt/municipio/concelho-de-felgueiras/breve-historia-do-concelho/

  As imagens presentes na página são interativas e permitem a sua ampliação ao clique, no entanto não apresentam qualquer indicação visual de que são elementos clicáveis no estado inicial. Desta forma, são percecionadas como conteúdo estático, o que pode dificultar a descoberta da funcionalidade de expansão por parte dos utilizadores.

  Recomendação:
  Recomenda-se adicionar indicadores visuais de interatividade às imagens clicáveis no estado inicial, de forma a tornar evidente que são elementos acionáveis.

  

  Ponto 06
  Páginas:
  https://cm-felgueiras.pt/municipio/concelho-de-felgueiras/contactos-uteis/
  https://cm-felgueiras.pt/servicos/regulamentos-e-posturas/

  Foram identificados botões interativos que apresentam contraste insuficiente entre o texto/ícone e o respetivo fundo.
  Adicionalmente, os estados dos botões (como hover, focus e active) não apresentam diferenciação visual suficiente, o que pode comprometer a identificação da sua interatividade, especialmente para utilizadores com baixa visão.

  Recomendação
  Ajustar as cores dos botões interativos para garantir contraste mínimo de 4.5:1 no texto e 3:1 nos componentes.
  Assegurar que os estados (hover, focus, active) são claramente visíveis, não dependendo apenas de pequenas variações de cor.
  Garantir um indicador de foco visível com contraste adequado

  

  Evidências em Darkmode
  Páginas:
  https://cm-felgueiras.pt/viver/coesao-e-acao-social/humanamente-iguais/
  https://cm-felgueiras.pt/viver/juventude/
  https://cm-felgueiras.pt/servicos/balcao-de-servicos/
  https://cm-felgueiras.pt/viver/protecao-civil/
  https://cm-felgueiras.pt/venha-experimentar-saborear-e-sentir-felgueiras/
  https://cm-felgueiras.pt/servicos/informacao-e-apoio-ao-consumidor/
  https://cm-felgueiras.pt/municipio/projetos-cofinanciados/

  Foram identificados problemas de contraste em elementos interativos, nomeadamente:
  setas de acordeões em dark mode, com baixa visibilidade face ao fundo
  botão “Ler mais/Recolher texto”, que apresenta baixo contraste e falta de destaque visual, comprometendo a perceção de interatividade

  Estas situações dificultam a identificação e utilização dos elementos, especialmente para utilizadores com baixa visão.

  

  Ponto 07
  Página: https://cm-felgueiras.pt/

  No rodapé do site https://cm-felgueiras.pt/
  os ícones das redes sociais são apresentados apenas como elementos visuais, sem qualquer indicação de interatividade ao passar o cursor (hover). Não existe alteração visual, destaque, sublinhado, mudança de cor ou outro feedback que indique ao utilizador que se tratam de elementos clicáveis.

  Esta ausência de feedback visual pode levar a que os utilizadores interpretem os ícones como elementos decorativos, dificultando a perceção de que são links para redes sociais, especialmente para utilizadores menos experientes ou em contextos de navegação por teclado/tecnologias de apoio.

  

  Recomendação
  Garantir que os elementos interativos apresentem affordance clara de interação. Recomenda-se adicionar estados de hover e focus visíveis (ex: alteração de cor, escala, sublinhado, ou outline), assegurando também um estilo consistente com links clicáveis.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #47 Formulário não lê labels e sequência de tabulação não é compreensível

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

  A sequência de tabulação entre campos segue a sequência de preenchimento.
  – ver requisito 1.1 na lista Transação

  Evidências:
  No formulário em formato PDF da página Discussão pública da proposta de 2.ª Alteração à 1.ª Revisão do Plano Diretor Municipal ao navegar com leitor de ecrã através de tabulação e outros modos de exploração, não é anunciado qualquer conteúdo associado aos campos. O foco do teclado percorre os elementos do formulário, no entanto não existe leitura de etiquetas (labels), instruções ou nomes de campos, resultando numa experiência completamente silenciosa para o utilizador. Na prática, os controlos são focáveis, mas não existe comunicação textual equivalente, o que impede a compreensão do propósito de cada campo e inviabiliza o preenchimento autónomo do formulário.

  

  Figura 1 – Exemplo de navegação no formulário PDF com leitor de ecrã ativo, onde o foco é visível mas não existe qualquer leitura de etiqueta ou descrição associada aos campos.

  Recomendações:
  Recomenda-se a revisão do PDF enquanto formulário interativo, garantindo que todos os campos possuem uma estrutura acessível adequada (tags corretas no PDF, campos de formulário devidamente etiquetados e associados semanticamente, e ordem de leitura definida).

  Deve ser assegurada a existência de nomes acessíveis para todos os campos (labels), bem como a correta definição da árvore de acessibilidade do documento, de forma a permitir que leitores de ecrã anunciem corretamente cada elemento durante a navegação. Recomenda-se ainda a validação do PDF com ferramentas de acessibilidade e leitores de ecrã antes da sua publicação.

  Uma solução mais acessível seria disponibilizar o formulário diretamente no site, em vez de em formato PDF. Os formulários em HTML são, de forma geral, mais fáceis de tornar acessíveis e proporcionam uma experiência mais robusta e consistente para utilizadores de tecnologias de apoio.

• evidência: issue #26 Botões de rádio não anunciam o rótulo do campo durante navegação por teclado

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

  Notas Gerais

  • Em formulários, os grupos de botões de rádio devem estar semanticamente associados a um rótulo (label), permitindo que as tecnologias de apoio anunciem corretamente o contexto de cada opção.
  • Durante a navegação por teclado (Tab e Shift+Tab), cada grupo deve ser identificado pelo seu nome acessível, garantindo que o utilizador compreende a que pergunta ou campo pertencem as opções apresentadas.

  URL a verificar

  • https://cm-felgueiras.pt/servicos/sistema-gestao-da-qualidade/inquerito-de-satisfacao-qualidade/

  Evidências

  No formulário de avaliação de experiência, ao navegar com as teclas Tab e Shift+Tab, a sequência de foco segue corretamente a ordem lógica de preenchimento.

  No entanto, nos campos compostos por botões de rádio (por exemplo: “Tempo de decisão/resposta”, “Clareza da Informação Recebida” e “Funcionamento do Serviço Prestado”), o leitor de ecrã não anuncia o rótulo do campo quando o foco entra no grupo.

  São apenas anunciadas as opções individuais (ex.: “Muito satisfeito, botão de opção marcado, 4 de 4”), sem referência ao contexto da pergunta a que pertencem.

  Este comportamento compromete a compreensão do formulário, uma vez que o utilizador não consegue identificar a que campo correspondem as opções apresentadas.

  

  Figura 1 – Formulário onde os campos não são anunciados corretamente e o leitor de ecrã apenas lê as opções como “lista”

  Recomendações

  Recomenda-se que os grupos de botões de rádio sejam corretamente associados a um rótulo acessível, por exemplo através da utilização de <fieldset> e <legend>, garantindo que o nome do campo é anunciado pelas tecnologias de apoio.

  Deve ser assegurado que, ao navegar por teclado, o leitor de ecrã comunica o contexto completo do campo antes das opções.

  Como referência de boa prática, pode ser consultado: https://webaim.org/techniques/forms/controls#radio

etiqueta: N/A

Lista de evidências recolhidas:

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

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

  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

  Não existem formulários com mais de 2 ecrãs no website, portanto o critério é considerado "Não aplicável (N/A)".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #34 Sequência de passos não acessível

  etiqueta: NOKetiqueta: 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

  URL a verificar

  • https://cm-felgueiras.pt/servicos/informacao-e-apoio-ao-consumidor/

  Evidências:
  Os formulários com várias páginas devem indicar claramente a sequência de passos e permitir a navegação entre eles.

  No formulário analisado, apesar de existirem várias etapas, a sequência de passos não é comunicada a utilizadores de leitores de ecrã, não sendo possível perceber em que fase do processo se encontram. Adicionalmente, não é garantido o acesso consistente aos passos anteriores através da navegação por teclado.

  Como consequência, o utilizador não tem perceção do progresso nem controlo completo sobre a navegação entre etapas, o que pode dificultar a conclusão do formulário.

  

  Figura 1 - Secção do formulário com indicação de passos não acessível através da navegação por teclado (Tab)

  Recomendações:
  Recomenda-se que a informação de progresso do formulário multi-etapas seja disponibilizada de forma acessível a tecnologias de apoio, garantindo que o passo atual, o total de passos e a designação da etapa são corretamente anunciados por leitores de ecrã.

  Deve ser assegurado que esta informação não dependa apenas de elementos visuais ou de componentes com aria-hidden="true", devendo existir uma alternativa textual acessível ou mecanismo equivalente que permita a comunicação do estado do formulário durante a navegação.

  Como exemplo de solução, pode ser utilizado um elemento com aria-live="polite" que seja atualizado sempre que o utilizador avança no formulário (ex.: “Passo 1 de 2 – Dados do Reclamante”), garantindo que esta informação é automaticamente anunciada pelas tecnologias de apoio.

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

Lista de evidências recolhidas:

• evidência: issue #61 Não existem restrições do tipo de caracteres a inserir nos campos

  etiqueta: melhoriaetiqueta: R 2.1etiqueta: chk transação

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

  Os campos de formulário que aceitam caracteres específicos, por exemplo, apenas números ou apenas letras, devem impedir a inserção de determinados tipos de caracteres. Desta forma, garantimos que não são inseridos caracteres errados, evitando possíveis erros.

  Verificámos que em alguns campos de formulários do Sítio Oficial da Câmara Municipal de Felgueiras, as restrições aplicadas aos tipos de caracteres não são adequadas ao conteúdo esperado. Por exemplo:

  • No campo “Telefone” (presente nos formulários das páginas Informação e Apoio ao Consumidor, no formulário “Enviar Mensagem” na página Sistema de Gestão de Qualidade, Atendimento Municipal e Contratação Pública) e no campo “NIF” (presente no formulário da página Contratação Pública) é possível inserir letras. Estes campos deveriam aceitar apenas números para evitar erros e garantir que a informação é introduzida corretamente.

  • No campo “Localidade” (presente nos formulários das páginas Informação e Apoio ao Consumidor, Atendimento Municipal e Contratação Pública) é possível inserir números. Este campo deveria aceitar apenas letras, espaços e hifens, de forma a refletir corretamente nomes de localidades.

  • No formulário em formato PDF “Formulário - alt2_rev1_pdm” (presente na página Discussão pública da proposta de 2.ª Alteração à 1.ª Revisão do Plano Diretor Municipal) nos campos “NIF/NIPC”, “Identificação Civil”, “Validade”, “Código Postal (CP)” e “Telefone” é possível inserir letras e/ou caracteres especiais como “#”, “$”, “%”, “&”, entre outros.

  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.

  

  Figura 1 - Formulário da página Contratação Pública onde, nos campos "NIF" e "Telefone", é possível inserir letras e caracteres especiais e, no campo "Localidade", é possível inserir números.

  

  Figura 2 - Formulário da página Informação e Apoio ao Consumidor. O campo "Localidade" está a aceitar números.

  

  Figura 3 - Teste do formulário em formato PDF “Formulário - alt2_rev1_pdm” (presente na página Discussão pública da proposta de 2.ª Alteração à 1.ª Revisão do Plano Diretor Municipal) onde as restrições aplicadas aos tipos de caracteres não são adequadas ao conteúdo esperado.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #74 Existem campos do formulário cuja legenda não é clara

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

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

  As legendas dos campos devem ser claras, curtas e concisas, para que sejam rapidamente entendidas pelo utilizador.

  Identificámos alguns casos em que isso não acontece. Um exemplo encontra se no formulário da página de Contratação Pública, no campo “Códigos CAE (Principal e Secundário/os)”.

  Primeiramente, é importante questionar se este campo é realmente necessário no formulário. Para além de acrescentar mais uma pergunta ao processo de preenchimento, trata se de uma informação que os utilizadores, na maioria das vezes, não sabem de memória. Caso optem por manter este campo, há ainda outro aspeto a considerar: a legenda indica que devem ser fornecidos dois ou mais códigos CAE (“Principal e Secundário/os”). No entanto, é disponibilizado apenas um único campo de input, o que pode gerar confusão.
  Uma solução possível seria criar um campo dedicado ao Código CAE Principal e, quando aplicável, outro(s) campo(s) para o(s) Código(s) CAE Secundário(s).

  Adicionalmente, junto destes campos, pode também ser indicado de forma clara, direta e objetiva onde é que o utilizador pode ter acesso a estes códigos.

  No formulário PDF “Formulário - alt2_rev1_pdm”, disponível na página Discussão pública da proposta de 2.ª Alteração à 1.ª Revisão do Plano Diretor Municipal, também identificámos vários campos cujas legendas não são suficientemente claras. Entre eles estão: “Nome/Denominação”, “NIF/NIPC”, “Validade”, “Domicílio/Sede”, “Representante”, “Domicílio” e “CP”.

  Caso o requerente e o representante forem entidades distintas, a informação pode ser separada em duas secções bem definidas: “Dados do Requerente” e “Dados do Representante”.

  Dentro de cada uma destas secções, devem ser utilizados rótulos mais claros e específicos como, por exemplo, “Nome completo”, “NIF” e “NIPC” (em campos separados, por serem dados diferentes), “Validade do Cartão de Cidadão” e “Código postal”.

  

  Figura 1 - Campo Códigos CAE (Principal e Secundário/os) no formulário da página de Contratação Pública.

  

  Figura 2 - Formulário PDF “Formulário - alt2_rev1_pdm”, disponível na página Discussão pública da proposta de 2.ª Alteração à 1.ª Revisão do Plano Diretor Municipal. Campos de formulário cuja legenda não é clara estão destacados através de um retângulo de borda roxa.

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

  Verificámos que, nos formulários das páginas Inquérito de Satisfação – Qualidade e Informação e Apoio ao Consumidor, existem campos que apresentam a indicação visual “(Obrigatório)” junto ao respetivo rótulo, mas que não estão programaticamente definidos como obrigatórios.

  No caso da página Inquérito de Satisfação – Qualidade, os radio buttons não têm associado o atributo required ou aria-required. Na página Informação e Apoio ao Consumidor, o campo de upload de ficheiro “Documento Complementar” também não possui qualquer um destes atributos.

  Recomendamos que, para além do texto “(Obrigatório)” em frente ao rótulo do campo seja também adicionado o atributo required ou aria-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.

  

  Figura 1 - Análise dos radio buttons dentro do campo "Tempo de decisão/resposta", na página Inquérito de Satisfação – Qualidade, através do Google Inspector.

  

  Figura 2 - Análise do botão "Seleccione os ficheiros" dentro do formulário da página Informação e Apoio ao Consumidor através do Google Inspector.

• evidência: issue #75 Não é possível identificar campos obrigatórios

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

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

  Verificámos que, no formulário “Formulário - alt2_rev1_pdm”, disponível na página Discussão pública da proposta de 2.ª Alteração à 1.ª Revisão do Plano Diretor Municipal, não é possível reconhecer os campos de preenchimento obrigatório. Esta informação não é passada quer visualmente quer para os leitores de ecrã.

  Uma solução mais acessível seria disponibilizar o formulário diretamente no site, em vez de em formato PDF. Nos formulários web, os campos obrigatórios devem incluir os atributos required ou aria-required=”true” para serem identificados pelas tecnologias de apoio como obrigatórios.

  Adicionalmente, deve ser apresentada uma indicação visual clara junto ao rótulo — por exemplo, “(Campo obrigatório)” — para que todos os utilizadores consigam identificar facilmente os campos que têm obrigatoriamente de preencher.

  

  Figura - Análise do formulário “Formulário - alt2_rev1_pdm”, disponível na página Discussão pública da proposta de 2.ª Alteração à 1.ª Revisão do Plano Diretor Municipal através do leitor de ecrã NVDA. Os campos de preenchimento obrigatório não estão identificados.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #18 Falta de feedback acessível no carregamento de e-books

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

  O sistema deve indicar o que está a acontecer quando determinadas ações são desencadeadas, principalmente quando o resultado não é imediato ou demora mais tempo do que é suposto.

  Ao selecionar um e-book, é apresentado um indicador de carregamento com a mensagem “Dearflip: Loading PDF x%”, enquanto o conteúdo é carregado. (Figura 1)

  

  Figura 1 - Mensagem de carregamento apresentada durante a abertura do e-book

  Apesar de existir feedback visual, a mensagem encontra-se em inglês e não descreve claramente o conteúdo que está a ser carregado (e-book), o que pode gerar alguma ambiguidade para os utilizadores.

  Para além disso, não é fornecida qualquer indicação acessível para utilizadores de leitores de ecrã. A mensagem de carregamento não é anunciada, nem é exposta de forma programática, o que impede estes utilizadores de perceberem que o sistema está a processar a ação. Esta situação pode levar à perceção de falha ou bloqueio da interface.

  URL a verificar

  • https://cm-felgueiras.pt/servicos/sistema-gestao-da-qualidade

  Recomendação
  Recomendamos apresentar uma indicação sobre o que está a acontecer de forma explícita e acessível durante o processo de carregamento do e-book.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #23 Mensagens de sucesso não acessíveis após submissão

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

  O sucesso de uma transação deve ser claramente comunicado ao utilizador.

  Ao realizar ações como a subscrição da newsletter, a apresentação de uma reclamação ou a resposta ao questionário, são apresentadas mensagens de sucesso visíveis na interface, como demonstrado nas seguintes figuras.

  

  Figura 1 - Mensagem de confirmação de subscrição da newsletter

  

  Figura 2 - Mensagem de sucesso após apresentação de reclamação

  

  Figuras 3 e 4 - Mensagens de sucesso após resposta aos questionários

  No entanto, estas mensagens não são acessíveis a utilizadores de leitores de ecrã, não sendo anunciadas automaticamente após a ação. Verifica-se ainda que, durante a navegação por teclado (Tab e Shift+Tab), o foco não percorre a mensagem de sucesso, impedindo o seu acesso por utilizadores que dependem exclusivamente deste modo de navegação.

  Esta situação ocorre porque a mensagem não recebe foco programático nem está integrada na ordem natural de tabulação, o que impede que seja alcançada e anunciada pelas tecnologias de apoio. Como consequência, os utilizadores podem não ter perceção de que a ação foi concluída com sucesso.

  URL a verificar

  • https://cm-felgueiras.pt/
  • https://cm-felgueiras.pt/cerimonia-oficial-ira-assinalar-certificacao-dos-bordados-terras-de-sousa-e-file-de-felgueiras/ (todas as notícias)

  Recomendação
  Após a submissão, o foco deve ser automaticamente movido para a mensagem de sucesso, garantindo que esta é imediatamente anunciada pelo leitor de ecrã.

  A mensagem deve também ser colocada na ordem de navegação por teclado, permitindo que possa ser novamente acedida através das teclas Tab e Shift+Tab.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #79 Os formulários do website não permitem ações destrutivas

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

  Os formulários analisados são formulários de submissão. Não foram identificadas situações em que estes formulários permitam ações destrutivas, como a exclusão ou remoção de informação previamente submetida. Por esse motivo, este critério é considerado “Não aplicável”.

etiqueta: NOK

Lista de evidências recolhidas:

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

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

  No formulário de Apresentação de Reclamação, as mensagens de erro são apresentadas no topo do formulário. Para além de não estarem associadas programaticamente aos respetivos campos, verifica‑se um segundo problema relacionado com a estrutura em etapas.

  O formulário está dividido em duas etapas:

  1. Dados do reclamante
  2. Dados do reclamado

  Quando o utilizador submete o formulário com erros, todas as mensagens de erro são exibidas no topo da primeira etapa, incluindo erros relativos a campos que pertencem à etapa 2, o que gera problemas, nomeadamente:

  • Quando se navega com o rato, teclado ou leitor de ecrã, as mensagens de erro não direcionam o utilizador para os campos com erro na etapa 2:

  

  • Quando o utilizador navega para a etapa 2, as mensagens de erro deixam de estar visíveis, impedindo a identificação dos campos incorretos:

  

  • Não são apresentadas mensagens de erro junto aos campos e as mensagens não estão associadas ao seu respectivo campo, o que dificulta a compreensão do que precisa de ser corrigido:

  

  URL a verificar

  • https://cm-felgueiras.pt/servicos/informacao-e-apoio-ao-consumidor/#gf_7

  Sugestão de correção

  • As mensagens de erro devem ser apresentadas junto ao respetivo campo e posicionadas imediatamente após o campo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #82 Não são devolvidas mensagens de erro em campos de formulários

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

  Os campos dos formulários devem devolver mensagens de erros relativas ao problema de preenchimento em cada campo, que devem ser identificadas visualmente e pelo leitor de ecrã.

  No formulário de Bolsa de Fornecedores não existe quaisquer mensagens de erro caso o utilizador insira dados incorretos nos campos de NIF, telefone e código postal que são campos numéricos:

  

  URL a verificar

  • Necessário verificar em todos os formulários do website.
    https://cm-felgueiras.pt/viver/contratacao-publica/
    https://cm-felgueiras.pt/servicos/balcao-de-servicos/
    https://cm-felgueiras.pt/servicos/sistema-gestao-da-qualidade/ - todas as páginas que apresentem a funcionalidade "Enviar mensagem"
    https://cm-felgueiras.pt/servicos/informacao-e-apoio-ao-consumidor/#gf_7

  Recomendação de melhoria

  • Devem rever todos os formulários para garantir que os campos devolvam mensagens de erro que ajudem o utilizador a preencher corretamente. Por exemplo, formato correto do telefone, NIF e código postal.

• evidência: issue #81 Formulários PDFs não apresentam mensagens de erro

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

  Verifica‑se que alguns formulários estão a ser disponibilizados no formato PDF. Embora seja tecnicamente possível tornar formulários em PDF acessíveis, isso exige um trabalho específico e cuidadoso — como definição de etiquetas, ordem de leitura, campos de formulário corretamente identificados e indicação de obrigatoriedade. Um PDF não se torna acessível de forma automática apenas por conter campos editáveis.

  Os formulários PDF do website da CM Felgueiras que foram avaliados, não transmitem mensagens de erro programaticamente e visualmente:

  

  URL a verificar

  • Necessário verificar todos os formulários em PDF do website
  • https://cm-felgueiras.pt/discussao-publica-da-proposta-de-2-a-alteracao-a-1-a-revisao-do-plano-diretor-municipal/#2622-2622-wpfd-top

  Recomendação de melhoria

  • Construir formulários utilizando elementos HTML e apresenta-los no website. Dessa forma garantimos que o seu preenchimento seja acessível para um maior número de pessoas, incluindo pessoas com necessidades especiais.
  • Devem garantir que as mensagens de erro sejam claras e que ajudem o utilizador durante o seu preenchimento.

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

Lista de evidências recolhidas:

• evidência: issue #76 Outras Violações - Registo incorreto de votos no questionário de satisfação

  etiqueta: melhoriaetiqueta: outras violações

  Verificámos que o questionário de satisfação “Qual o seu grau de satisfação com a informação desta página?” presente em algumas páginas do Sítio Oficial da Câmara Municipal de Felgueiras, como na página Projeto da 1.ª Alteração do Regulamento “Felgueiras + Acessível: Empresas” – Início de Procedimento, não está a registar corretamente o número de votos nas diferentes opções de resposta (“Insatisfeito”, “Parcialmente satisfeito”, “Satisfeito” e “Muito satisfeito”). Sugerimos refletir sobre a utilidade desta funcionalidade para os utilizadores e considerar, se necessário, a sua remoção.

  

  Figura - Questionário de satisfação “Qual o seu grau de satisfação com a informação desta página?” presente na página Projeto da 1.ª Alteração do Regulamento “Felgueiras + Acessível: Empresas” – Início de Procedimento. Os votos estão a ser contados incorretamente e transmitidos ao leitor de ecrã.

• evidência: issue #63 Outras violações - Há links nos acordões que não estão a funcionar

  etiqueta: melhoriaetiqueta: outras violações

  Descrição do problema

  Na página de Informação e Apoio ao Consumidor, os links disponibilizados no acordeão não se encontram funcionais. Ao selecionar alguns dos links, o utilizador é indevidamente redirecionado para uma página com erro “Not Found”, comprometendo o acesso à informação.

  Este problema verifica-se, nomeadamente, na secção "Direitos e deveres do consumidor" com o link para o site do www.consumidor.pt (Figura 1 e 2)

  

  Figura 1- Contéudo indisponível no acordeão

  

  Figura 2- Erro no link com redirecionamento para página "No found"

  E na secção "Hiperligações" com o link para o Centro Europeu do Consumidor, afetando a usabilidade, a confiança no serviço digital e o acesso equitativo à informação.(Figura 03)

  

  Figura 3- Site do "Centro Europeu do Consumidor" com erro de acesso

  Recomendação de melhoria:
  Recomenda-se a verificação e correção dos links disponibilizados no acordeão da página, garantindo que todos os endereços estejam atualizados e funcionais. Desta maneira evitam redirecionamentos para páginas de erro e asseguram o acesso contínuo, fiável e inclusivo à informação.

• evidência: issue #53 Outras violações - Sobreposição de menus e navegação redundante na versão mobile

  etiqueta: melhoriaetiqueta: outras violações

  Descrição do problema

  Considerando que o menu principal e o menu secundário apresentam opções semelhantes, funcionando este último como uma navegação alternativa, a melhoria de acessibilidade deve centrar‑se na prevenção da sobreposição de menus.

  Na versão mobile do website, é possível abrir o menu principal e o menu secundário em simultâneo, o que resulta na sobreposição de conteúdos e na falta de clareza da navegação, transmitindo uma sensação de navegação redundante, com duplicação de opções já existentes no menu principal (Figura 1).

  

  Figura 1 - Sobreposição de menu principal e secundário

  Este comportamento gera confusão para o utilizador, dificulta a perceção da hierarquia da informação e aumenta a probabilidade de erros de interação, sobretudo em ecrãs pequenos. Para utilizadores de tecnologias de apoio, a existência de menus simultaneamente abertos e com links repetidos compromete a previsibilidade e a eficiência da navegação.

  Recomendação:
  Garantir que, na versão mobile, apenas um menu possa estar ativo de cada vez, evitando sobreposição de conteúdos e comportamentos redundantes.