Relatório Avaliação de Candidatura
Agenda Municipal de Machico

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #50 O menu principal está construído de forma inapropriada

  etiqueta: NOKetiqueta: R 1.1etiqueta: chk 10 web

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

  • Ver requisito 1.1 da lista 10 aspetos

  Evidências:

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

  Como resultado, os leitores de ecrã interagem apenas parcialmente com o componente de tabulação, o que provoca inconsistências e dificuldades de navegação.

  

  Componente tabulador tablist visível para o menu desktop

  URLs a verificar:

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

  Recomendações:

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

• evidência: issue #44 As opções do rodapé não estão estruturadas como uma lista

  etiqueta: NOKetiqueta: R 1.1etiqueta: chk 10 web

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

  • Ver requisito 1.1 da lista 10 aspetos

  Evidências:

  No rodapé as opções estão sendo agrupadas por div genéricas:

  

  URLs a verificar:

  • https://agenda.cm-machico.pt/ - menu do rodapé

  Recomendações:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: NOKetiqueta: R 1.2etiqueta: chk 10 web

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

  • Ver requisito 1.2 da lista 10 aspetos

  Evidências:

  Verifica-se que não está a ser utilizado a tag nav no menu. Ao utilizar o leitor de ecrã, não é possível realizar saltos diretamente para o menu, nem este é identificado como uma área de navegação:

  

  URLs a verificar:

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

  Recomendações:

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

• evidência: issue #47 Não é possível identificar quando o menu está aberto ou fechado com o leitor de ecrã

  etiqueta: NOKetiqueta: R 1.2etiqueta: chk 10 web

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

  • Ver requisito 1.2 da lista 10 aspetos

  Evidências:

  A abertura e fecho do menu não está a ser informada para os leitores de ecrã. Isso acontece porque não está a ser utilizado o atributo aria-expanded:

  

  URLs a verificar:

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

  Recomendações:

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

• evidência: issue #45 O foco do leitor de ecrã é direcionado automaticamente para a opção "Submeter evento"

  etiqueta: NOKetiqueta: R 1.2etiqueta: chk 10 web

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

  • Ver requisito 1.2 da lista 10 aspetos

  Evidências:

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

  

  URLs a verificar:

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

  Recomendações:

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #53 As imagens do menu principal possuem texto alternativo incorreto

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 1.3

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

  • Ver requisito 1.3 da lista 10 aspetos

  Evidências:

  Foi verificado que o nome acessível dos botões de abrir e fechar o menu está a ser fornecido através do atributo title.

  Além disso, os textos utilizados não descrevem corretamente a ação disponível. Quando o menu se encontra fechado, o botão é anunciado como "Menu | Agenda Machico", enquanto, quando o menu está aberto, é anunciado como "Fecha Menu | Agenda Machico". O comportamento esperado seria que os nomes acessíveis descrevessem a ação que será executada, utilizando designações como "Abrir menu" e "Fechar menu".

  O atributo title destina-se a disponibilizar informação complementar ou contextual e não deve ser utilizado como mecanismo principal para fornecer o nome acessível de um controlo interativo. Neste caso, o nome do botão constitui informação essencial para compreender a sua função e deve ser disponibilizado através dos mecanismos apropriados de acessibilidade.

  A utilização do title como única fonte do nome acessível pode originar comportamentos inconsistentes entre diferentes tecnologias de apoio e não garante uma experiência de utilização uniforme.

  

  URLs a verificar:

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

  Recomendações:

  • Remover o atributo title quando este estiver a ser utilizado apenas para fornecer o nome acessível do botão.
  • Garantir que o nome acessível é disponibilizado através de mecanismos apropriados, como texto visível ou aria-label, conforme a implementação do componente.
  • Atualizar dinamicamente o nome acessível para refletir a ação disponível, utilizando designações como "Abrir menu" quando o menu estiver fechado e "Fechar menu" quando estiver aberto.
  • Reservar a utilização do atributo title apenas para informação complementar que acrescente contexto ao utilizador, evitando a sua utilização para transmitir informação essencial sobre a função do controlo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #73 Utilização de um título h1 genérico nas páginas da Agenda Municipal

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 2.1

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

  • Ver requisito 2.1 da lista 10 aspetos

  Evidências:

  Foi verificado que todas as páginas do website utilizam o mesmo elemento <h1>, com o texto "Agenda Municipal de Machico", independentemente do conteúdo apresentado.

  O elemento <h1> deve identificar o título principal de cada página e refletir o respetivo conteúdo. A utilização de um título genérico em todas as páginas compromete a estrutura semântica do website e dificulta a identificação do conteúdo por utilizadores de tecnologias de apoio.

  

  Figura 1 - Exemplo de utilização do mesmo elemento <h1> ("Agenda Municipal de Machico") em diferentes páginas do website.

  URLs a verificar:

  Verificar todas as páginas do portal da Agenda Municipal.

  • https://agenda.cm-machico.pt/menu/lista-de-eventos/lista-de-eventos-desporto-e-aventura

  Recomendações:

  • Garantir que cada página contém um único elemento <h1>, correspondente ao respetivo conteúdo principal.
  • Substituir o título genérico "Agenda Municipal de Machico" por um título que identifique corretamente o conteúdo de cada página.
  • Rever todas as páginas do website, assegurando que o elemento <h1> representa de forma única e descritiva o tema principal de cada uma.

• evidência: issue #71 Utilização de dois elementos h1 na mesma página

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 2.1

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

  • Ver requisito 2.1 da lista 10 aspetos

  Evidências:

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

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

  Esta duplicação poderá gerar problemas caso ambos os cabeçalhos h1 fiquem visíveis para os leitores de ecrã.

  

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

  URLs a verificar:

  https://agenda.cm-machico.pt/acessibilidade

  Recomendações:

  • Remover o título genérico "Machico Resolve" da página de Declaração de Acessibilidade e Usabilidade.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #79 Saltos na hierarquia de cabeçalhos

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

  Evidências:

  Nas páginas analisadas, foram identificados saltos na hierarquia de cabeçalhos (ex.: utilização de <h3> sem existência prévia de <h2>).

  Estas inconsistências comprometem a correta estrutura semântica das páginas e dificultam a navegação por utilizadores de tecnologias de apoio.

  

  Figura 1 - Salto na hierarquia de cabeçalhos, com utilização de <h3> sem <h2>.

  URLs a verificar:

  https://agenda.cm-machico.pt/

  Recomendações:

  • Implementar uma hierarquia consistente de cabeçalhos (<h1>–<h6>) em todas as páginas, respeitando a ordem sequencial, sem saltos de níveis.
  • Garantir que cada página contém um único <h1>, correspondente ao conteúdo principal.
  • Rever a estrutura semântica das páginas de forma a assegurar que os níveis de cabeçalhos refletem corretamente a relação hierárquica entre secções e subseções.

• evidência: issue #72 Cabeçalhos incorretamente marcados

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

  Evidências:

  Foram identificados vários títulos de secções e subtítulos do website que se encontram marcados com elementos <div> em vez de elementos de cabeçalho (<h1>–<h6>).

  Embora estes elementos sejam apresentados visualmente como títulos, a ausência de marcação semântica adequada impede que sejam reconhecidos como cabeçalhos pelas tecnologias de apoio, comprometendo a estrutura hierárquica da página e dificultando a navegação por utilizadores de leitores de ecrã.

  As Figuras 1 a 4 apresentam alguns exemplos desta situação, verificando-se a utilização de elementos <div> para representar títulos de secções do website.

  

  Figura 1 - Título da secção "Machico Cultural e Artístico" marcado com um elemento <div> .

  

  Figura 2 - Título da secção "Desporto e Aventura" marcado com um elemento <div> .

  

  Figura 3 - Título da secção "Conhecimento e Aprendizagem" marcado com um elemento <div> .

  

  Figura 4 - Título da secção "Categorias" marcado com um elemento <div> .

  URLs a verificar:

  https://agenda.cm-machico.pt/

  Recomendações:

  • Substituir os elementos <div> utilizados como títulos ou subtítulos por elementos de cabeçalho (<h1>–<h6>), de acordo com a respetiva função na página.
  • Garantir que a hierarquia de cabeçalhos é consistente e reflete corretamente a estrutura lógica do conteúdo.
  • Rever todas as páginas do website para identificar situações semelhantes, assegurando que os títulos de secções e subseções utilizam marcação semântica adequada.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #74 Não foram identificadas tabelas

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

  As células que constituem os cabeçalhos da tabela estão marcadas com o elemento <th>.
  – ver requisito 3.1 na lista 10 aspetos

  Evidências:

  Não foram identificadas tabelas no website, tornando este critério N/A.

  URLs a verificar:

  Recomendações:

  Nada a acrescentar.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #75 Não foram identificadas tabelas

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

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

  Evidências:

  Não foram identificadas tabelas no website, tornando este critério N/A.

  URLs a verificar:

  Recomendações:

  Nada a acrescentar.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #63 Não é possível localizar e ler as mensagens de erro usando apenas um leitor de ecrã

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 4.3

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

  Evidências:

  Verifica-se que a mensagem de erro associada ao campo Email só se torna visível após o campo receber foco e ser abandonado pelo utilizador, não sendo apresentada no momento da validação inicial ou da submissão do formulário.
  Como consequência, no primeiro acesso ao campo, o leitor de ecrã não anuncia a existência do erro associado. A mensagem apenas é comunicada caso o utilizador retorne novamente ao campo, o que pode dificultar a identificação e correção do problema.

  

  ---

  Verifica-se que, quando o campo Email é preenchido com um formato incorreto, não é apresentada uma mensagem de validação junto ao respetivo campo.

  A ausência desta mensagem dificulta a identificação do erro e não fornece ao utilizador orientação sobre o formato esperado para correção da informação introduzida. Recomenda-se que seja apresentada uma mensagem de validação na proximidade do campo Email, de forma visual e programaticamente associada ao campo.

  

  URLs a verificar:
  https://agenda.cm-machico.pt/menu/submeter-evento

  Recomendações:
  Recomenda-se a implementação de mensagens de erro para os campos de formulário, de forma que, sempre que ocorra um erro de validação, seja apresentada uma mensagem visível na proximidade do respetivo campo. Cada mensagem deve identificar claramente o erro ocorrido e, sempre que aplicável, indicar ao utilizador como o pode corrigir.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: NOKetiqueta: R 5.1etiqueta: chk 10 web

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

  Evidências:
  Verifica-se que a imagem do logótipo apresenta um texto alternativo definido como: alt="Logo_AgendaMachico". Além de não descrever adequadamente a imagem ou a finalidade do elemento, o texto alternativo utiliza a palavra “logo”, o que é desnecessário, uma vez que os leitores de ecrã já identificam o conteúdo como imagem. Recomenda-se substituir o valor do atributo alt por um texto mais claro e descritivo, como “Agenda Machico”.

  

  ---

  Verifica-se que o marcador do mapa (Leaflet) é focável (tabindex="0") e tem alt="", porém o leitor de ecrã anuncia o nome do ficheiro: "Pin_geral.svg, clicável, imagem" não comunicando informação útil sobre o ponto assinalado. Neste caso como o mapa apresenta controlos de zoom acessíveis e pode ter utilidade para alguns utilizadores, incluindo pessoas com visão parcial que utilizam leitor de ecrã, recomenda-se que o marcador tenha um nome acessível adequado, que identifique a localização representada, como o endereço, local do evento ou coordenadas.

  

  URLs a verificar:
  https://agenda.cm-machico.pt/
  https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/3506-blasted-mechanism-na-semana-gastronomica-de-machico-2026

  Recomendações:

  • As imagens não decorativas devem possuir uma descrição breve e adequada, disponibilizada por meio do atributo alt, descrevendo corretamente o conteúdo ou a função da imagem apresentada. Recomenda-se que o texto alternativo seja claro, objetivo e não utilize caracteres especiais desnecessários.
  • Para o mapa, deve-se inserir um nome acessível que identifique a localização representada, como o endereço, local do evento ou coordenadas.

• evidência: issue #4 (Melhoria) Imagem decorativa com texto alternativo indevido

  etiqueta: melhoriaetiqueta: R 5.1etiqueta: chk 10 web

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

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

  

  URLs a verificar:
  (verificar em todo website)

  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/3431-sessao-informativa-prevencao-de-incendios-rurais
  • https://agenda.cm-machico.pt/

  Recomendações:

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

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: NOKetiqueta: R 5.2etiqueta: chk 10 web

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

  Evidências:

  Verifica-se que o texto associado à imagem não apresenta uma descrição completa do conteúdo disponibilizado visualmente, nomeadamente da tabela de jogos a realizar.

  A descrição apresentada é genérica e não comunica informações essenciais presentes na imagem, como as seleções envolvidas, as datas e os horários dos jogos. Além disso, não é disponibilizado um link ou alternativa textual que permita aos utilizadores aceder a essas informações de forma equivalente.

  

  ---

  Verifica-se que as imagens utilizadas para representar as opções de layout da página de detalhe apresentam um equivalente alternativo insuficiente. As imagens possuem um texto alternativo genérico, como alt="Layout 1", que apenas identifica a opção, mas não descreve a informação visual apresentada. Dessa forma, utilizadores de tecnologias de apoio não conseguem compreender a organização dos elementos representados na imagem, como a posição da imagem, do texto e dos restantes componentes do layout.

  Tendo em conta que estas imagens transmitem informação necessária para a escolha do layout, recomenda-se que seja disponibilizada uma descrição textual equivalente e completa para cada opção. Esta descrição pode ser associada ao respetivo controlo através do atributo aria-describedby.

  

  URLs a verificar:

  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/3273-xi-torneio-intermunicipios-entre-16-e-19-de-julho
  • https://agenda.cm-machico.pt/menu/submeter-evento

  Recomendações:

  • Recomenda-se que o conteúdo relevante da imagem seja disponibilizado em texto dentro da label. A imagem pode ser decorativa.
  • Para as imagens utilizadas para representar as opções de layout no formulário, a descrição deve ser associada via aria-describedby. Por exemplo:

  <input
    type="radio"
    id="layout-1"
    name="layout"
    value="1"
    aria-describedby="layout-1-desc">
  
  <label for="layout-1">
    
  
  <!--IMAGE_PLACEHOLDER_2-->
  
  
    <span>Opção Layout 1</span>
  </label>
  
  <p id="layout-1-desc">
    Layout com imagem principal no topo, seguida de blocos de texto e informação complementar organizados abaixo da imagem.
  </p>
  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #3 Imagem link sem texto alternativo

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 5.3

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

  Evidências:

  Verifica-se que a imagem do logótipo, utilizada como hiperligação para a página inicial, apresenta um texto alternativo que não descreve adequadamente o propósito do link (acesso à página inicial).

  Adicionalmente, verifica-se que o nome acessível está a ser fornecido através do atributo title, o que não é recomendado como mecanismo principal de acessibilidade. Recomenda-se que o equivalente textual seja disponibilizado diretamente no elemento interativo (<a>) através do atributo aria-label. O title deve ser removido.

  

  ---

  Verifica-se que a imagem-link utilizada para permitir o acesso ao topo da página não apresenta um nome acessível para utilizadores de tecnologias de apoio.

  Tratando-se de uma hiperligação representada apenas por um elemento visual, deve ser disponibilizado um equivalente textual que descreva claramente a sua finalidade. Neste caso, recomenda-se que o nome acessível seja definido no próprio mecanismo interativo, por exemplo através do atributo aria-label, indicando a ação esperada, como “Voltar ao topo”.

  

  ---

  Verifica-se que, na secção Principais Eventos, a imagem do cartaz e o título do evento estão implementados como hiperligações separadas, embora apontem para o mesmo destino.

  Na estrutura HTML analisada, a imagem do cartaz encontra-se dentro de um elemento e, logo de seguida, o título do evento surge também dentro de outro elemento , ambos direcionando para a mesma página do evento. Esta implementação gera links duplicados adjacentes, o que pode tornar a navegação por teclado e por tecnologias de apoio mais repetitiva e menos clara para o utilizador.

  Neste caso, recomenda-se combinar a imagem e o título do evento numa única hiperligação, garantindo que o texto visível do título identifica o destino do link. Assim, a imagem pode ser tratada como decorativa através de alt="", evitando a repetição desnecessária de links para o mesmo recurso.

  

  ---

  • Imagem-link da galeria
    Verifica-se que, o texto alternativo definido no atributo alt não descreve corretamente a imagem apresentada, e a presença simultânea de um aria-label faz com que o leitor de ecrã anuncie apenas este último, ignorando o alt. Como resultado, o texto alternativo deixa de ser efetivamente utilizado.

  

  • Imagem ampliada da galeria
    A imagem ampliada deve apresentar o mesmo texto alternativo da imagem-link, garantindo consistência na identificação do conteúdo visual. No entanto, nesse caso, o alt não deve incluir a indicação “abrir galeria”, uma vez que a ação já foi executada e a imagem ampliada deve apenas descrever o conteúdo efetivamente apresentado.

  

  ---

  Verifica-se também que, na página “Lista de Eventos”, as imagens associadas a cada evento estão estruturadas fora do respetivo link. Recomenda-se que a imagem seja incluída dentro do elemento de link correspondente, mantendo o atributo alt="", uma vez que a informação relevante já deve ser transmitida pelo texto do link associado.

  

  URLs a verificar:

  • https://agenda.cm-machico.pt/
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2204-mercado-quinhentista (deve ser alterado em todas as galerias de imagens)
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/

  Recomendações:

  • Recomenda-se definir um nome acessível por meio do atributo aria-label, garantindo que a finalidade do link seja corretamente comunicada às tecnologias de apoio.
  • Ajustar o nome acessível para identificar a finalidade e o destino do link, por exemplo: aria-label="Agenda Machico - página inicial"
  • Nas imagens da Galeria: deve ser definido no alt um texto alternativo que descreva a imagem apresentada, removido o atributo aria-label da imagem-link e integrada no atributo alt a indicação da ação disponível, isto é, que a imagem permite abrir a galeria.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #42 O texto normal não tem contraste suficiente em certos estados

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

  Evidências

  • O contraste no texto normal (menor que 18 pontos ou menor que 14 pontos negrito) das páginas deve ser, no mínimo 4,5:1, para que as pessoas com baixa visão consigam ler o texto. Este contraste é aplicado a todos os estados dos elementos (normal, hover, focus, etc).

  O website apresenta o menu “Machico Digital” problemas de contraste no estado de hover nas suas opções, onde texto normal utiliza a combinação de cores #FFFFFF(cor de primeiro plano) e #0098D8(cor de plano de fundo) o que torna os textos pouco visíveis. (Figura 1)

  

  Figura 1- Menu "Machico Digital" texto em estado de hover com problemas de contraste, com uma taxa de apenas 3,2:1 não passam na avaliação de contraste com a ferramenta Colour Contrast Analyser

  A página inicial apresenta problemas de contraste em estado de hover de textos de botões e no menu principal, por exemplo com as opções de segundo nível que apresentam uma taxa de contraste de apenas 1,8:1 na combinação das cores #08D6DC(cor de primeiro plano) e #FFFFFF(cor de plano de fundo). Por exemplo na opção do menu “Semana Gastronómica de Machico” e na secção Multimédia (Figura 2 e 3)

  

  Figura 2- Falha na avaliação de contraste em texto normal em textos do menu

  

  Figura 3- Textos de hiperligação na secção “Multimédia” com problema de contraste em estado de hover

  URLs a verificar

  • https://agenda.cm-machico.pt/ (Rever todo website)
  • Menu principal (Menu principal e textos de hiperligações em estado de hover)

  Recomendações
  Recomendamos a revisão das combinações de cores de todos textos normais da páginas no website para garantir os valores mínimos de contraste do texto normal. Garantir consistência nos estados visuais (normal, hover, foco) com contraste adequado;

  • Caso exista texto normal com pouco contraste, em que as cores utilizadas sejam as mesmas do logótipo da entidade, recomendamos a substituição dessas cores por outras que garantam um contraste mínimo de 4,5:1. Por exemplo, podem ser usados tons semelhantes ao do logotipo ou outras cores da identidade gráfica da marca.

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

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

  Evidências

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

  O website apresenta problemas de contraste no texto normal em formulários, nomeadamente nas mensagens de erro no símbolo de * para os campos obrigatórios, por exemplo no formulário Submeter evento, onde utilizam nas mensagens de erro, a combinação de cores #E73D4A(cor de primeiro plano) e #FFFFFF(cor de plano de fundo) que torna os textos pouco visíveis. (Figura 1 e 2)

  

  Figura 1- Mensagens de erro com problemas de contraste, com uma taxa de apenas 4,06:1 na avaliação com a ferramenta WAVE

  

  Figura 2 - Mensagens de erro para "Campo de preenchimento obrigatório" com problema de contraste em todo formulário

  Esta implementação dificultando perceção e compromete a leitura e interpretação da informação, afetando diretamente a legibilidade especialmente para utilizadores com baixa visão.

  URLs a verificar

  • https://agenda.cm-machico.pt/menu/submeter-evento (Rever contraste em textos normais das mensagens de erro)

  Recomendações
  Recomendamos a revisão das combinações de cores das páginas de todo website para garantir os valores mínimos de contraste do normal. Garantir consistência nos estados visuais (normal, hover, foco) com contraste adequado;

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

Lista de evidências recolhidas:

• evidência: issue #43 Há texto sob imagens que não cumpre o rácio de contraste

  etiqueta: melhoriaetiqueta: chk 10 webetiqueta: R 6.2

  O rácio de contraste entre a cor do texto de tamanho grande (maior ou igual que 18 pontos ou maior ou igual que 14 pontos negrito) e a cor do fundo é superior a 3:1.
  – ver requisito 6.2 na lista 10 aspetos

  Evidências
  Os textos de tamanho superior a 18 pontos, ou os textos de tamanho superior a 14 pontos mas a negrito, devem assegurar um rácio de contraste mínimo de 3:1 entre a cor do texto e a cor do fundo, para que as pessoas com baixa visão consigam ler o texto.

  • É necessário também garantir que os textos por cima de imagens possuem contraste, principalmente quando a imagem é alterada ao longo do tempo, mas o estilo do texto mantém-se.

  No website, há imagens promocionais disponíveis no website que não apresentam contraste insuficiente em textos grandes, por exemplo na página inicial com imagem destaque do “IX Festival do Atum, do Gaiado e do Marisco” utilizando nos textos as combinações (cor #00AFEE) e o fundo (#FFFFFF). A análise de contraste demonstra que a combinação não cumpre o presente requisito, comprometendo a legibilidade, especialmente para utilizadores com baixa visão. (Figura 1 e 2)

  

  Figura 1 - Cartaz destaque na página inicial com problemas de contraste em texto grande, na análise com a ferramenta Colour Contrast Analyser

  

  Figura 2 - Conteúdo também está disponível no menu “Cartazes”, com uma taxa de apenas 2,5:1 para texto grande

  URLs a verificar

  • https://agenda.cm-machico.pt/ - Evento em destaque na página inicial apresenta problemas de contraste no texto grande
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2225-semana-gastronomica-de-machico (Cartaz do IX Festival do Atum, do Gaiado e do Marisco) - Evento disponível na secção “Cartazes”

  Recomendações
  Recomendamos a revisão das cores das páginas para garantir os valores mínimos de contraste do texto grande.Sugerimos que escureçam as imagens dos cartazes por exemplo, colocando um filtro, para que os textos fiquem mais legíveis.

  • Caso exista texto grande com pouco contraste, em que as cores utilizadas sejam as mesmas do logótipo da entidade, recomendamos a substituição dessas cores por outras que garantam um contraste mínimo de 3:1. Por exemplo, podem ser usados tons semelhantes ao do logotipo ou outras cores da identidade gráfica da marca.

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

Lista de evidências recolhidas:

• evidência: issue #78 Visibilidade do foco nos controlos do leitor multimédia

  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

  Evidências:

  Durante a navegação por teclado no leitor multimédia, verificou-se que os controlos podem ser alcançados através da tecla Tab. No entanto, nem sempre é evidente qual o elemento que possui o foco naquele momento.

  A reduzida visibilidade do indicador de foco dificulta a navegação por teclado, obrigando o utilizador a percorrer os controlos de forma tentativa até identificar a ação que será executada.

  Adicionalmente, em algumas situações, a área do vídeo apresenta um comportamento visual inconsistente durante a navegação pelos controlos, tornando menos clara a identificação do elemento atualmente selecionado.

  

  Figura 1 - Exemplo de navegação por teclado no leitor multimédia, onde a indicação visual do foco não é suficientemente evidente .

  URLs a verificar:

  Verificar todos os eventos no website com conteúdo multimédia.

  https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2225-semana-gastronomica-de-machico

  Recomendações:

  • Reforçar a visibilidade do foco nos controlos do leitor multimédia através de um indicador visual mais evidente.
  • Garantir que todos os elementos interativos do leitor apresentam um estado de foco claramente identificável durante a navegação por teclado.
  • Validar o comportamento visual do leitor durante a navegação por teclado, assegurando que o conteúdo multimédia e os controlos são apresentados de forma consistente.
  • Considerar a adoção de estilos de foco com contraste adequado e facilmente percetíveis pelos utilizadores.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #77 Ausência de legendas sincronizadas nos conteúdos multimédia

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 7.2

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

  Evidências:

  Foram identificados conteúdos multimédia que não disponibilizam legendas sincronizadas.

  A ausência de legendas sincronizadas adequadas dificulta o acesso à informação por pessoas surdas ou com deficiência auditiva, bem como por utilizadores que não podem reproduzir áudio no momento da consulta.

  

  Figura 1 - Exemplo de conteúdo multimédia sem legendas sincronizadas ._

  URLs a verificar:

  Verificar todos os eventos no website com conteúdo multimédia.

  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2114-12-feira-do-livro-de-machico-francisco-alvares-de-nobrega
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2207-festival-do-atum-do-gaiado-e-do-marisco
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2225-semana-gastronomica-de-machico

  Recomendações:

  • Disponibilizar legendas fechadas sincronizadas para todos os conteúdos multimédia.
  • Sempre que possível, utilizar legendas revistas manualmente em vez de depender exclusivamente das legendas automáticas da plataforma.
  • Garantir que as legendas reproduzem de forma fiel o conteúdo verbal relevante apresentado no vídeo.
  • Incluir, quando aplicável, informação sobre sons relevantes para a compreensão do conteúdo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #33 Ordem lógica comprometida na pesquisa e controlos associados

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.2

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

  Evidências:
  Na página observada, em ecrãs de menor dimensão, a funcionalidade de pesquisa e os respetivos controlos apresentam problemas na organização estrutural do conteúdo, afetando a sequência lógica de leitura e interação.

  • Formulário de pesquisa exposto fora de contexto

  O formulário de pesquisa avançada permanece disponível na árvore de acessibilidade mesmo quando visualmente oculto, podendo ser percorrido por leitores de ecrã antes da ativação da funcionalidade.

  

  Figura 1 - Formulário de pesquisa avançada exposto na árvore de acessibilidade antes da sua ativação

  • Botão de pesquisa posicionado fora da ordem lógica

  O botão de abertura da pesquisa encontra-se posicionado após a listagem de eventos no código HTML, não seguindo a ordem lógica esperada de interação.

  

  Figura 2 - Botão de pesquisa posicionado após a listagem de eventos no DOM

  • Controlo redundante sem função clara

  Existe ainda um segundo controlo de pesquisa implementado como botão composto ( com input interno), sem função clara adicional face ao restante mecanismo de pesquisa.

  <button id="peOustide" style="display: inline-block;">
      <div class="borda"></div>
      <input type="button" id="pesquisarEvento" value="Pesquisar">
  </button>
  

  Este elemento não apresenta uma função claramente diferenciada ou necessária, podendo gerar confusão na navegação.

  

  Figura 3 - Botão de pesquisa redundante sem função claramente identificável

  URLs a verificar:

  • https://agenda.cm-machico.pt/menu/lista-de-eventos

  Recomendações:

  • Garantir que o formulário de pesquisa permanece oculto da árvore de acessibilidade enquanto não estiver visível.
  • Utilizar mecanismos apropriados de ocultação como hidden, display: none ou aria-hidden="true" enquanto o painel está fechado.
  • Reorganizar a estrutura HTML de forma a garantir a sequência lógica:
    • botão de pesquisa
    • formulário de pesquisa
    • listagem de resultados
  • Remover ou clarificar a necessidade funcional de controlos redundantes ou sem função aparente.
  • Evitar a utilização de elementos interativos aninhados (button com input) que não acrescentem comportamento adicional.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #61 Seletor de idioma com estrutura semântica inadequada e controlos redundantes

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

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

  Evidências:
  Na página observada, o seletor de idioma apresenta diversos problemas de estrutura e semântica:

  As opções de idioma ("PT" e "EN") são apresentadas como ligações independentes, sem qualquer estrutura semântica que as identifique como um conjunto de opções relacionadas.
  O idioma atualmente selecionado é identificado apenas visualmente através de classes CSS, não existindo uma indicação programática do estado ativo.
  Adicionalmente, o seletor interno do Google Translate permanece exposto na árvore de acessibilidade, disponibilizando uma extensa lista de idiomas que duplica a funcionalidade já disponibilizada pelos controlos "PT" e "EN".

  Como consequência, os utilizadores de tecnologias de apoio podem percorrer controlos redundantes e ter maior dificuldade em compreender qual o mecanismo adequado para alterar o idioma da página.

  

  Figura 1 - Seletor de idioma composto por ligações sem estrutura semântica e exposição do seletor completo do Google Translate na árvore de acessibilidade.

  URLs a verificar:

  • https://agenda.cm-machico.pt/ (em todo o website)

  Recomendações:

  • Estruturar o conjunto de idiomas utilizando elementos HTML semânticos apropriados (por exemplo, uma lista dentro de um elemento <nav>).
  • Identificar programaticamente o idioma atualmente selecionado (por exemplo, recorrendo a aria-current, quando aplicável).
  • Evitar expor na árvore de acessibilidade controlos redundantes que não façam parte da interface pretendida para o utilizador.
  • Garantir que apenas o mecanismo de seleção de idioma efetivamente disponibilizado na interface é apresentado às tecnologias de apoio.

• evidência: issue #58 Controlos interativos redundantes em cards de eventos

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

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

  Evidências:

  Na listagem de eventos foi identificado que cada card contém um botão "Saber Mais" implementado com o elemento <button>.

  Durante os testes efetuados, verificou-se que este botão:

  • recebe foco através da navegação por teclado;
  • é anunciado pelos leitores de ecrã como um botão;
  • não executa qualquer ação quando ativado com Enter ou Espaço.

  A navegação para o detalhe do evento é assegurada exclusivamente pelo link principal do card, pelo que o botão "Saber Mais" não possui qualquer funcionalidade efetiva.

  Como consequência, os utilizadores podem ser levados a acreditar que existe uma ação disponível quando, na realidade, o controlo não produz qualquer resultado, comprometendo a clareza da interface e a semântica dos elementos interativos.

  

  Figura 1 - Botão "Saber Mais" recebe foco e é anunciado como elemento interativo, mas não executa qualquer ação.

  URLs a verificar:

  • https://agenda.cm-machico.pt/menu/lista-de-eventos

  Recomendações:

  • Remover o botão "Saber Mais" caso não tenha qualquer funcionalidade.
  • Caso deva encaminhar para o detalhe do evento, implementar essa ação corretamente ou substituí-lo pelo link já existente.
  • Garantir que todos os elementos interativos expostos na interface executam efetivamente a ação anunciada ao utilizador.

• evidência: issue #55 Controlos de fecho de modal implementados com elementos não semânticos

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

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

  Evidências:

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

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

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

  

  Figura 1 - Controlo de fecho de modal implementado com <div> em vez de <button>

  URLs a verificar:

  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2225-semana-gastronomica-de-machico
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2204-mercado-quinhentista
  • (outras páginas de cartazes com galeria de fotos)

  Recomendações:

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

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

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

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

  Evidências

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

  O contentor principal da modal é apresentado como:

  <div class="modalGaleriaGaleria" style="">

  No entanto:

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

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

  

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

  URLs a verificar:

  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2225-semana-gastronomica-de-machico
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2204-mercado-quinhentista
  • (outras páginas de cartazes com galeria de fotos)

  Recomendações

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

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

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

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

  Evidências:

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

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

  

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

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

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

  URL a verificar

  • https://agenda.cm-machico.pt/menu/lista-de-eventos
  • (outras páginas com elementos semelhantes)

  Recomendações:

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

• evidência: issue #34 Ausência de landmarks semânticos

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.3

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

  Evidências

  Observa-se a ausência de landmarks semânticos que permitam identificar programaticamente as principais regiões da página (ex.: cabeçalho, navegação, conteúdo principal e rodapé). A estrutura da interface aparenta estar predominantemente assente em elementos genéricos (<div> e <section>), sem utilização consistente de elementos HTML semânticos ou roles equivalentes.

  A inexistência destas regiões semânticas dificulta a navegação por tecnologias de apoio, nomeadamente leitores de ecrã, impedindo os utilizadores de saltar rapidamente entre áreas relevantes da página.

  

  Figura 1 - Ausência de landmarks semânticos identificáveis na estrutura da página

  URLs a verificar

  • https://agenda.cm-machico.pt/menu/lista-de-eventos (em todo o website)

  Recomendações

  • Implementar landmarks semânticos para as principais regiões da página, recorrendo preferencialmente a elementos HTML nativos como <header>, <nav>, <main> e <footer>
  • Garantir a existência de uma única região principal (<main>) por página
  • Quando não for possível utilizar elementos HTML semânticos, aplicar roles ARIA equivalentes, como role="banner", role="navigation", role="main" e role="contentinfo"
  • Validar a estrutura semântica com tecnologias de apoio para confirmar que as regiões são corretamente identificadas e anunciadas ao utilizador.

  Referência: MDN – ARIA landmark roles

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #51 Ticker de notícias/eventos com movimento automático sem mecanismo percetível de controlo

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 8.4

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

  Evidências:

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

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

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

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

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

  

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

  URL a verificar:

  • https://agenda.cm-machico.pt/ (Homepage - ticker de eventos)

  Recomendações

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

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.1

  Quando a caixa de diálogo é aberta, o foco (cursor do Browser) move-se para um elemento dentro da caixa de diálogo
  – ver requisito 9.1 na lista 10 aspetos

  Evidências:

  Validado que ao abrir a caixa de diálogo o cursor não se move automaticamente pra dentro da caixa de diálogo.

  

  ---

  Verifica-se que ao abrir a modal de erros do formulário, o foco não move-se para o primeiro elemento interativo dentro da modal.

  

  URLs a verificar:

  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2057-5-edicao-do-dog-trail
  • https://agenda.cm-machico.pt/menu/submeter-evento

  Recomendações:
  Quando a caixa de dialogo é aberta o foco deve ser posicionado no primeiro elemento interativo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #21 O foco não fica limitado a caixa de diálogo

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.2

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

  Evidências:

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

  

  URLs a verificar:

  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2057-5-edicao-do-dog-trail
  • https://agenda.cm-machico.pt/menu/submeter-evento

  Recomendações:

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #32 Ao fechar a caixa de diálogo o cursor não retorna ao elemento que o acionou

  etiqueta: NOKetiqueta: chk 10 webetiqueta: R 9.4

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

  Evidências:

  Verifica-se que ao fechar a caixa de diálogo o foco não retorna ao elemento que o acionou, o foco é reposicionado noutro elemento da página, o que pode causar desorientação para utilizadores que navegam por teclado ou com tecnologias de apoio. Este comportamento dificulta a continuidade da navegação, uma vez que o utilizador perde a referência do ponto onde se encontrava antes da abertura da modal.

  

  ---

  Verifica-se que, ao fechar a modal de aviso, o foco é encaminhado automaticamente para os campos do formulário que apresentam erro, permitindo ao utilizador revê-los e corrigi-los. Se este comportamento for mantido, recomenda-se substituir o botão “Fechar” apresentado actualmente por um botão com texto descritivo, que indique claramente a acção seguinte, por exemplo: “Fechar e corrigir campos assinalados”.

  Caso se opte por manter o botão atual, o comportamento mais adequado será devolver o foco ao botão “Enviar”, que foi o elemento que accionou a modal. Desta forma, evita-se uma mudança inesperada de contexto e garante-se uma navegação mais previsível e coerente para o utilizador.

  

  URLs a verificar:

  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2057-5-edicao-do-dog-trail
  • https://agenda.cm-machico.pt/menu/submeter-evento

  Recomendações:

  • Recomenda-se que ao fechar a modal, o foco seja devolvido ao elemento que a acionou.
  • Para a modal de erro do formulário: recomenda-se inserir um botão com texto descritivo que indique claramente a acção seguinte após o fecho da modal ou, em alternativa, ajustar o comportamento para que o foco regresse ao botão “Enviar”, que accionou a modal.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #76 Não foram identificados ficheiros PDF no portal

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

  Nos ficheiros PDF é possível, no mínimo, extrair o conteúdo textual para formato TXT.
  – ver requisito 10.1 na lista 10 aspetos

  Evidências:

  Não foram identificados ficheiros PDF no portal da Agenda Municipal de Machico, tornando este critério N/A.

  URLs a verificar:

  Recomendações:

  Nada a acrescentar.

• evidência: issue #70 R 10.1 - 10 Aspetos

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

  Nos ficheiros PDF é possível, no mínimo, extrair o conteúdo textual para formato TXT.
  – ver requisito 10.1 na lista 10 aspetos

  Evidências:
  Não foi identificado ficheiros PDF no website. Por esse motivo, consideramos o critério como "Não aplicável".

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

  Evidências:

  Na página principal do website da Agenda de Machico, não aparece presente um resumo breve do próposito do site.

  

  Imagem da página principal sem fazer scroll

  URLs a verificar:

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

  Recomendações:

  O propósito deve transmitir, de forma clara, o que o utilizador pode efetivamente encontrar e realizar no website. Esse propósito deve ser imediatamente visível na página, sem ser necessário fazer scroll, avançar no slideshow, entre outros.

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

  

  Imagem exemplo de uma frase de propósito do website selo.usabilidade.gov

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

  Evidências:

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

  

  Imagem com vários termos complexos sem definição agregada. Disponível em: https://agenda.cm-machico.pt/menu/regras-de-utilizacao

  

  Imagem com o termo complexo "ADRAP" sem definição agregada. Disponível em: https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2214-xxvi-circuito-de-agua-de-pena-em-atletismo

  URLs a verificar:

  • https://agenda.cm-machico.pt/ - MMTC no "Agenda por temas" do menu principal
  • https://agenda.cm-machico.pt/menu/submeter-evento - NIF e NIPC
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2213-rampa-regional-do-porto-da-cruz-cs-maritimo-2022 - AMAK e CS
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2211-3-prova-2022-campeonato-regional-da-madeira-de-motocross - CS
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2205-iv-edicao-do-neon-color-run-2022 - AARAM
  • entre outros

  Recomendações:

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

  Como exemplo podem visualizar o glossario do acessibilidade.gov.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #37 R 2.1 - Conteúdo -O conteúdo do site fica desformatado em resoluções mais pequenas

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

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

  O website apresenta inconsistências na variação dos tamanhos de letra em resoluções mais reduzidas. Com a navegação verificou‑se que, ao alterar a resolução para um formato mobile, o texto de botões do menu principal ficam com uma dimensão inferior à recomendada, comprometendo a legibilidade. (Figura 1)

  

  Figura 1 - Textos dos eventos destaque com apenas 14px

  Além disso, na página Submeter Eventos, os rótulos dos campos de preenchimento cumprem o valor recomendado em desktop, mas em versões mobile sofre alterações com o tamanho de letra de apenas 14px. (Figura 2)

  

  Figura 2 - Rótulo “NIF/NIPC” não cumpre valor mínimo recomendado em versões mobile

  O mesmo problema verifica-se na variação dos tamanhos dos textos dos botões na “Lista de eventos”. Na versão para dispositivos móveis, o texto apresenta um tamanho inferior, enquanto noutros dispositivos chega mesmo a desaparecer (Figuras 3 e 4).

  

  Figura 3 - Botão “Lista de eventos” com apenas 15px na versão iPad Air

  

  Figura 4 - Botão “Pesquisa” com apenas 15px, e “Lista de eventos” não está disponível na versão iPhone 14 Pro Max

  URLs a verificar

  • https://agenda.cm-machico.pt/ (Conteúdos da página inicial com textos variáveis em dispositivos móveis)
  • https://agenda.cm-machico.pt/menu/submeter-evento - (Labels em formulários com textos variáveis)
  • https://agenda.cm-machico.pt/menu/lista-de-eventos - (Botão: “Lista de eventos” e “Pesquisar”)

  Recomendação

  É necessário a revisão em todo website. Para correção das páginas adaptadas de modo a assegurar que o conteúdo se reorganiza corretamente e permanece totalmente utilizável em diferentes resoluções, tamanhos e orientações de ecrã, sem perda de informação ou funcionalidade.

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

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

  Evidências

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

  O website possui informações primárias com tamanho inferior a 12pontos(16px). Na página inicial as descrições breves referente aos conteúdos dos “Eventos” apresentam tamanho de letra inferior ao mínimo recomendado. (Figura 1)

  

  Figura 1 - Textos informativos dos eventos com apenas 15px
  

  Além disso, o website apresenta botões com tamanho de texto inferior ao recomendado. Como por exemplo nas páginas interiores da Lista eventos, por exemplo a página Concurso cinematográfico “MachiCurtas”. (Figura 2)

  

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

  O formulário Lista de eventos, possui filtros de categorias e textos em placeholders nos campos de preenchimentos, com textos que possuem tamanho de letra de apenas 14px. (Figura 3)

  

  O formulário Lista de eventos, possui filtros de categorias e textos em placeholders nos campos de preenchimentos, com textos que possuem tamanho de letra de apenas 14px. O mesmo acontece no formulário Submeter evento com textos de preenchimento obrigatório e mensagens de erro. (Figura 3 e 4)

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

  

  Figura 4 - Textos de mensagens de erro considerados informações primárias com apenas 14px

  URLs a verificar

  • https://agenda.cm-machico.pt/menu/lista-de-eventos (Revisar tamanho de letra em todo website)
  • https://agenda.cm-machico.pt/menu/submeter-evento (Informações primárias em formulários)
  • (Botões “Anterior e Seguinte” em páginas interiores)
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/3567-concurso-cinematografico-machicurtas
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/1954-aldeia-natal-em-machico-2024_

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

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.2

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

  Evidências

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

  Durante a análise foram identificadas informações secundárias apresentadas com um tamanho de letra inferior ao mínimo recomendado. Por exemplo, na página Lista de eventos, onde as tags referentes ao mês do evento apresenta textos com tamanho inferior ao recomendado. (Figura 1)

  

  Figura 1 - Verificação do tamanho de letra na tag do evento, onde o texto referente ao mês possui apenas 12px

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


  URLs a verificar

  • https://agenda.cm-machico.pt/menu/lista-de-eventos

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #39 Existem blocos de textos com mais de 100 caracteres por linha

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.3

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

  Evidências

  • Para assegurar uma boa leitura, as linhas de texto devem ter até 80 caracteres (incluindo espaços). No limite, podem ir até aos 100 caracteres (incluindo espaços).

  Verificámos que no website há blocos de textos apresentam largura superior ao recomendado por linha. Por exemplo na página Regras de utilização (Figura 1)

  

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

  URLs a verificar

  • https://agenda.cm-machico.pt/menu/regras-de-utilizacao (174 caracteres)
  • https://agenda.cm-machico.pt/acessibilidade (198 caracteres)
  • https://agenda.cm-machico.pt/menu/noticias-agenda/detalhe/2444-sopas-com-historia-2024 (180 caracteres)

  Recomendações
  Revisar blocos de textos para garantir que não é ultrapassado o número máximo de caracteres por linha. Recomendamos que seja definida uma largura máxima para as caixas de texto (max-width, em CSS), com unidades relativas ao tamanho de fonte (unidades em ou rem).

  • Nota: Rever todo website não apenas o apontamentos aqui colocados. Para cumprir o critério, é necessário corrigir larguras de blocos de textos e garantir uma leitura confortável para todos utilizadores de maneira transversal em todo o website.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #17 Excesso de opções no menu principal

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 3.1

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

  Evidências:

  Os menus de navegação devem se manter equilibrado, nem com demasiadas opções de topo sem opções secundárias, nem com poucas opções de topo e muitas opções secundarias. Nenhum nível de navegação deve ter mais de 9 opções, mas neste caso a subopção "Agenda por tema" contêm 10 opções.

  

  URLs a verificar:

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

  Recomendações:

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

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

  • Reduzir o número de opções no subnível, agrupando conteúdos relacionados sob categorias mais abrangentes.
  • Utilizar rótulos claros e consistentes que facilitem a identificação rápida das secções.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #18 A navegação principal do site está colapsada em desktop

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 3.2

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

  Evidências:

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

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

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

  

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

  URLs a verificar:

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

  Recomendações:

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #19 Falta de identificação complementar nas hiperligações

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

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

  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:

  

  Links no ticker de notícas na página inicial.

  

  Links do breadcrumb sem idicação de hiperligação.

  URLs a verificar:

  • https://agenda.cm-machico.pt/ - breadcrumbs, links na barra superior ("Machico Digital" e "Lista de eventos") e título das notícias/desportos/eventos/conferências

  Recomendações:

  • 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 #29 Páginas extensas sem índice de navegação interna entre secções

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

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

  Evidências:

  Verificamos que a página Acessibilidade, apresenta um conteúdo extenso, com mais de três ecrãs de informação, sem disponibilizar um índice no topo da página com hiperligações internas para as respetivas secções. Esta situação dificulta a navegação e a localização rápida da informação disponibilizada. (Figura 01)

  

  Figura 01 — Página "Acessibilidade" sem índice de navegação interna.

  URL a verificar:

  • https://agenda.cm-machico.pt/acessibilidade

  Recomendações:

  Recomendamos a inclusão de um índice de navegação imediatamente após o título principal da página (H1), contendo hiperligações internas para as principais secções do conteúdo. No caso da página "Acessibilidade", o índice poderá incluir ligações para secções como "Estado de conformidade", "Elaboração da presente declaração de acessibilidade e usabilidade", "Contacto e solicitação de informação relativa ao sítio Web", "Outras evidências" e "Denúncia de situações de discriminação".

• evidência: issue #28 Imagens de grande dimensão aumentam a extensão da página

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

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

  Evidências:

  Verificámos que a página Festa de Nossa Senhora da Guadalupe apresenta uma extensão superior a três ecrãs, em grande parte devido à utilização de imagens de elevada dimensão ao longo do conteúdo. Considerando que as imagens podem ser ampliadas através de seleção, poderá ser avaliada a redução da sua dimensão na página ou a disponibilização de mecanismos adicionais de navegação, contribuindo para uma experiência de consulta mais eficiente. (Figura 01)

  

  Figura 01 — Imagens de grande dimensão contribuem para a extensão da página.

  URL a verificar:

  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2201-festa-de-nossa-senhora-da-guadalupe - (Verificar paginas de eventos do website)
  • https://agenda.cm-machico.pt/menu/noticias-agenda/detalhe/3574-campeonato-da-europa-de-biatle-triatle-e-laser-run-20260623165524 - (Verificar paginas de notícias de acontencimentos do website)

  Recomendações:

  Avaliar a redução da dimensão das imagens apresentadas ao longo da página, mantendo a possibilidade de ampliação através da funcionalidade já existente. Esta abordagem poderá contribuir para uma navegação mais fluida e para a redução da extensão total da página.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #31 O layout do sítio Web é adaptável a plataformas móveis sem necessidade de efetuar varrimento horizontal

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

  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

  Evidências:

  O critério está a cumprir.

  Não foram identificadas recomendações para este requisito, uma vez que o website apresenta um comportamento responsivo adequado nas páginas analisadas.

  

  Figura 01 — Layout apresentado corretamente em dispositivo móvel, sem necessidade de varrimento horizontal.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #49 Elementos interativos dependentes de interação por hover para visualização

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

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

  Evidências:

  Verificamos que, no rodapé do website Agenda Machico, o logótipo "my travel guide" apenas é apresentado quando o utilizador interage com a área através de hover. Esta funcionalidade depende exclusivamente da interação com o rato, não estando disponível da mesma forma em dispositivos táteis ou para utilizadores que não utilizem hover. (Figura 01)

  

  Figura 01 — Logótipo "my travel guide" apresentado apenas em estado hover no rodapé do website.

  URL a verificarL:

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

  Recomendações:

  Garantir que os elementos interativos se encontram permanentemente visíveis ou disponíveis através de diferentes formas de interação, não dependendo exclusivamente da passagem do rato para serem apresentados.

  Desta forma, assegura-se o acesso à mesma funcionalidade por utilizadores de dispositivos de toque e outras formas de navegação.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #25 Elementos interativos com área clicável inferior à dimensão mínima recomendada de 44px CSS

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

  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

  Evidências:

  Verificamos que, na página inicial do website [Agenda Machico], existem elementos interativos com dimensões inferiores ao mínimo recomendado de 44px × 44px.

  A título de exemplo, o botão "Menu" apresenta uma altura de 34,38px. (Figura 01)

  

  Figura 01 — Botão "Menu" com altura 34.38 px inferior à dimensão recomendada.

  As opções de seleção de idioma "EN" e "PT" apresentam dimensões inferiores à recomendada, sendo que a opção "PT" possui uma dimensão de 12,91 × 26,4px. (Figura 02)

  

  Figura 02 — Opções de seleção de idioma com 12.91 x 26.4 px dimensões inferiores à recomendada.

  O botão "Voltar ao topo" possui uma dimensão de 40px. (Figura 03)

  

  Figura 03 — Botão "Voltar ao topo" com 40px dimensão inferior à recomendada.

  Verificamos que os botões "Anterior" e "Seguinte", utilizados na navegação entre notícias, possuem dimensões inferiores ao mínimo recomendado para elementos interativos. A título de exemplo, na página GNR na Semana Gastronómica de Machico 2026, estes botões apresentam uma altura de 27.6px, valor inferior à dimensão mínima recomendada de 44px. (Figura 04)

  

  Figura 04 — Botões "Anterior" e "Seguinte" com altura 27.6px inferior à dimensão recomendada.

  Verificamos que, na página da notícia Festa de Nossa Senhora da Guadalupe, o botão de fecho ("X") disponibilizado na visualização ampliada das imagens da galeria possui uma dimensão de 35px, valor inferior à dimensão mínima recomendada de 44px para elementos interativos. (Figura 05)

  

  Figura 05 — Botão de fecho da galeria com dimensão 35px inferior à recomendada.

  Verificamos que, na página Submeter Evento, alguns elementos interativos apresentam dimensões inferiores ao mínimo recomendado de 44px.

  Os botões de opção radio buttons "Sim" e "Não" possuem uma dimensão de 33.42 × 19.99px. (Figura 06)

  

  Figura 06 — Botões de opção "Sim" e "Não" com dimensão inferior à recomendada.

  as caixas de seleção associadas às opções de consentimento, possuem uma altura de 28.57px, abaixo da dimensão mínima recomendada de 44px para elementos interativos. (Figura 07)

  

  Figura 07 — Caixas de seleção de consentimento com dimensão inferior à recomendada.

  Verificamos que os botões de partilha nas redes sociais, presentes na página Festival do Atum, do Gaiado e do Marisco, apresentam dimensões inferiores ao mínimo recomendado de 44px para elementos interativos. A título de exemplo, o botão de partilha para o Facebook apresenta uma dimensão de 38 × 38.85px. (Figura 08)

  

  Figura 08 — Botão de partilha com dimensão inferior à recomendada.

  URLs a verificar:

  • https://agenda.cm-machico.pt/
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/3505-gnr-na-semana-gastronomica-de-machico-2026 - (Verificar todas as páginas de notícias do website).
  • https://agenda.cm-machico.pt/menu/submeter-evento
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2207-festival-do-atum-do-gaiado-e-do-marisco

  Recomendações:

  Recomendamos que todos os elementos interativos do website disponham de uma área clicável mínima de 44px × 44px, aumentando as suas dimensões ou a respetiva área de interação sempre que necessário, sem comprometer a apresentação visual da interface.
  Esta verificação deverá abranger botões, ligações, opções de seleção (radio buttons), caixas de seleção (checkboxes), botões de partilha, controlos de navegação e restantes elementos interativos do website.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #27 Elementos interativos sem diferenciação visual clara ou comportamento consistente de interação

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.4

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

  Evidências:

  Verificamos que, na página inicial do website Agenda Machico, alguns elementos interativos não apresentam características visuais que permitam identificar claramente a sua funcionalidade.

  A título de exemplo, a ação "Ver Todos", presente em várias secções da página, como na secção "Machico Cultural e Artístico", é apresentada de forma semelhante a texto comum, dificultando a perceção do elemento como interativo. (Figura 01)

  

  Figura 01 — Ação "Ver Todos" sem indicação visual clara de interação.

  Na secção "Principais Eventos", os cartazes dos eventos são clicáveis, mas não apresentam características visuais que permitam identificar claramente essa funcionalidade. Adicionalmente, não existe qualquer alteração visual em estado hover que reforce a perceção de interação. Esta situação pode dificultar a identificação dos cartazes como elementos interativos. (Figura 02)

  

  Figura 02 — Cartazes de eventos clicáveis sem indicação visual de interação.

  Os elementos "Machico Digital" e "Lista de Eventos", presentes no cabeçalho do website, são clicáveis, mas não apresentam características visuais que permitam identificar claramente essa funcionalidade. A sua apresentação é semelhante à de texto informativo, podendo dificultar a perceção da interação disponível. (Figura 03)

  

  Figura 03 — Elementos clicáveis apresentados sem indicação visual de interação.

  Verificamos que, na página Lista de Eventos - Cultural e Artístico, a ação "Limpar filtro" é apresentada de forma semelhante a texto comum, sem indicadores visuais que permitam identificar claramente a sua funcionalidade. Esta situação pode dificultar a perceção do elemento como interativo. (Figura 04)

  

  Figura 04 — Ação "Limpar filtro" sem diferenciação visual face ao conteúdo envolvente.

  Verificamos que, na página da notícia Festa de Nossa Senhora da Guadalupe, as imagens disponibilizadas na galeria podem ser selecionadas para visualização, mas não apresentam indicadores visuais que permitam identificar claramente essa funcionalidade. (Figura 05)

  

  Figura 05 — Imagens da galeria sem indicação visual da funcionalidade de ampliação.

  URLs a verificar:

  • https://agenda.cm-machico.pt/
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/lista-de-eventos-cultural-e-artistico
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/lista-de-eventos-desporto-e-aventura
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/lista-de-eventos-cartazes
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2201-festa-de-nossa-senhora-da-guadalupe
  • https://agenda.cm-machico.pt/multimedia

  Recomendações:

  Recomendamos que os elementos interativos sejam apresentados com características visuais que permitam identificar claramente a sua funcionalidade. Sempre que aplicável, deverão ser utilizados indicadores como alteração de cor, sublinhado, ícones, contornos ou efeitos nos estados hover e foco, de forma consistente em todo o website, permitindo distinguir facilmente elementos clicáveis de conteúdo meramente informativo.

• evidência: issue #26 Elementos interativos com contraste insuficiente relativamente ao fundo

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.4

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

  Evidências:

  Verificamos que, na página inicial do website Agenda Machico, alguns elementos interativos apresentam um contraste inferior ao mínimo recomendado.

  A título de exemplo, o controlo de navegação do banner principal apresenta um contraste de 1.22:1 face ao fundo envolvente, dificultando a sua identificação e utilização. (Figura 01)

  

  Figura 01 — Controlo de navegação do banner com contraste inferior ao recomendado.

  O botão "Voltar ao topo", apresenta contraste insuficiente face ao fundo em algumas secções da página. A título de exemplo, quando o botão é apresentado sobre a secção "Principais Eventos", identificámos um contraste de 1.13:1. (Figura 02)

  

  Figura 02 — Botão "Voltar ao topo" com contraste inferior ao recomendado sobre determinadas secções da página.

  Verificamos que, na galeria de imagens da página Festa de Nossa Senhora da Guadalupe, os controlos de navegação do carrossel apresentam contraste insuficiente face ao conteúdo em determinadas imagens. A título de exemplo, identificámos um contraste de 1:1 entre o controlo de navegação e a imagem de fundo, valor inferior ao mínimo recomendado para componentes de interface. Esta situação dificulta a identificação e utilização da funcionalidade disponível. (Figura 03)

  

  Figura 03 — Contraste insuficiente do controlo de navegação do carrossel em determinadas imagens da galeria.

  O botão "Lista de Eventos", presente no menu principal em todas as páginas do website, apresenta uma relação de contraste de 1.79:1, abaixo do mínimo recomendado. (Figura 04)

  

  Figura 04 — Contraste insuficiente no botão "Lista de Eventos" do menu principal.

  O botão "Novo Evento", no estado hover, apresenta igualmente uma relação de contraste inferior ao valor exigido, identificamos um contraste de 1.81:1. (Figura 05).

  

  Figura 05 — Contraste insuficiente do botão "Novo Evento" no estado hover.

  O ícone "X" do botão de fechar o menu principal apresenta uma relação de contraste de 2.97:1, também inferior ao valor exigido. (Figura 06)

  

  Figura 06 — Contraste insuficiente no ícone "X" de fechar do menu principal.

  Verificamos que os ícones apresentados nos cartões da secção "Info", na página Semana Gastronómica de Machico, apresentam contraste insuficiente face ao fundo do respetivo cartão. A título de exemplo, o ícone do cartão "Momentos 2024" apresenta um contraste de 1.41:1, valor inferior ao mínimo recomendado. (Figura 07)

  

  Figura 07 — Ícone do cartão "Momentos 2024" com contraste inferior ao recomendado.

  URLs a verificar:

  • https://agenda.cm-machico.pt/
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2225-semana-gastronomica-de-machico (Verificar paginas de eventos do website)

  Recomendações:

  Recomendamos que todos os componentes de interface do website apresentem uma relação de contraste mínima de 3:1 face ao fundo em todos os estados de interação (normal, hover, foco e ativo).
  Esta verificação deverá abranger botões, ícones, controlos de navegação, elementos de carrosséis e restantes componentes interativos, garantindo que permanecem facilmente identificáveis independentemente do conteúdo ou da secção da página onde são apresentados.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

  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

  Evidências:

  Não foram encontrados formulários com mais de dois ecrãs no site Agenda Machico. Assim, este critério é considerado "Não aplicável (N/A)".

etiqueta: N/A

Lista de evidências recolhidas:

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

  etiqueta: chk transaçãoetiqueta: N/Aetiqueta: 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

  Evidências:

  Não foram encontrados formulários com mais de uma página dentro do site Agenda Machico. Assim, este requisito fica avaliado como "Não Aplicável".

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

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

  

  Figura – Análise do campo “Nome do Evento” no formulário da página Submeter Evento. Este campo foi destacado através de um retângulo de borda preta.

  URL a verificar:
  Página Submeter Evento

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #67 Há campos dependentes de outros campos que estão imediatamente visíveis mas estão inativos

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

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

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

  Evidências:
  No formulário da página Submeter Evento, o campo Subcategoria (dependente do campo anterior Categoria) está visível, mas inativo por defeito.

  

  Figura – Análise do campo Subcategoria, do formulário da página Submeter Evento, através do Google Inspector.

  URL a verificar:
  Página Submeter Evento – Campo Subcategoria

  Recomendações:
  Recomendamos que o campo Subcategoria seja totalmente ocultado, tanto na interface como para tecnologias de apoio. Este campo só deve ser apresentado ao utilizador depois de o campo Categoria, do qual depende, ter sido preenchido.

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

Lista de evidências recolhidas:

• evidência: issue #68 Rótulos apresentados depois dos controlos

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

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

  Evidências:
  Ao analisar a página Lista de Eventos, identificámos um problema na estrutura dos campos de formulário: o rótulo () está colocado depois do controlo do formulário (<input> ou <select>).
  Por exemplo:

  • No campo “Nome do Evento”, que é um campo de texto, o código HTML apresenta primeiro o elemento <input> e só depois o <label>.

  • No campo “Categoria”, que é uma lista suspensa, o <select> aparece antes do <label>.
    Esta ordem incorreta faz com que, ao usar um leitor de ecrã, o utilizador ouça primeiro o tipo de componente e o seu estado (por exemplo, “Caixa de combinação recolhido requerido entrada válida”) e só depois o rótulo do campo (“Categoria”). Isto pode causar confusão, especialmente para quem navega apenas através do leitor de ecrã.

  

  Figura 1 – Análise do campo “Nome do Evento”, do formulário da página Lista de Eventos, através do Google Inspector.

  

  Figura 2 – Análise do campo “Categoria”, do formulário da página Lista de Eventos, através do Google Inspector.

  URLs a verificar:

  • Página Lista de Eventos – Campos: Nome do Evento, Categoria, Freguesia, Mês.
  • Página Lista de Eventos – Cultural e Artístico – Campos: Nome do Evento, Categoria, Freguesia, Mês.
  • Página Lista de Eventos – Desporto e Aventura – Campos: Nome do Evento, Categoria, Freguesia, Mês.
  • Página Lista de Eventos – Conhecimento e Aprendizagem – Campos: Nome do Evento, Categoria, Freguesia, Mês.
  • Página Lista de Eventos - Cartazes – Campos: Nome do Evento, Categoria, Freguesia, Mês.

  Recomendações:
  Para garantir uma navegação acessível e clara, recomendamos que o elemento <label> seja sempre colocado antes do controlo do formulário, como <input> ou <select>. Para mais informações sobre como estruturar diferentes tipos de campos de formulários podem consultar a página Creating Accessible Forms da WebAIM.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #69 Campos obrigatórios sem indicação visual

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

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

  Evidências:
  Verificámos que, por exemplo, em todos os campos do formulário da página Lista de Eventos, todos os campos estão programaticamente marcados como obrigatórios (através do atributo required). No entanto, não há indicação visual de que estes campos são obrigatórios.

  

  Figura – Análise do campo “Nome do Evento”, da página Lista de Eventos – Cultural e Artístico, através do Google Inspector. O atributo required está destacado através de um retângulo de borda preta.

  URLs a verificar:

  • Página Lista de Eventos – Campos: Nome do Evento, Categoria, Freguesia, Mês.

  • Página Lista de Eventos – Cultural e Artístico – Campos: Nome do Evento, Categoria, Freguesia, Mês.

  • Página Lista de Eventos – Desporto e Aventura – Campos: Nome do Evento, Categoria, Freguesia, Mês.

  • Página Lista de Eventos – Conhecimento e Aprendizagem – Campos: Nome do Evento, Categoria, Freguesia, Mês.

  • Página Lista de Eventos - Cartazes – Campos: Nome do Evento, Categoria, Freguesia, Mês.

  Recomendações:
  Caso considerem estes campos como obrigatórios, estes devem ser identificados com o texto “Obrigatório” após o rótulo do campo. Em alternativa, pode também ser usado o símbolo asterisco (*) e o respetivo significado no início do formulário.
  Caso considerem que estes campos como opcionais, o atributo required deve ser retirado do elemento.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

  Evidências:
  Na análise realizada, não foram identificadas ações longas que exijam comunicação de estado ao utilizador.
  Desta forma, considera-se que o critério é não aplicável.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

  Evidências:

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #64 As mensagens de erro não são apresentadas junto aos campos de origem

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

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

  Evidências:

  Verifica-se que a mensagem de erro associada ao campo Email só se torna visível após o campo receber foco e ser abandonado pelo utilizador, não sendo apresentada no momento da validação inicial ou da submissão do formulário.
  Como consequência, no primeiro acesso ao campo, o leitor de ecrã não anuncia a existência do erro associado. A mensagem apenas é comunicada caso o utilizador retorne novamente ao campo, o que pode dificultar a identificação e correção do problema.

  

  ---

  Verifica-se que, quando o campo Email é preenchido com um formato incorreto, não é apresentada uma mensagem de validação junto ao respetivo campo.

  A ausência desta mensagem dificulta a identificação do erro e não fornece ao utilizador orientação sobre o formato esperado para correção da informação introduzida. Recomenda-se que seja apresentada uma mensagem de validação na proximidade do campo Email, de forma visual e programaticamente associada ao campo.

  

  URLs a verificar:
  https://agenda.cm-machico.pt/menu/submeter-evento

  Recomendações:
  Recomenda-se a implementação de mensagens de erro para os campos de formulário, de forma que, sempre que ocorra um erro de validação, seja apresentada uma mensagem visível na proximidade do respetivo campo. Cada mensagem deve identificar claramente o erro ocorrido e, sempre que aplicável, indicar ao utilizador como o pode corrigir.

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

Lista de evidências recolhidas:

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

  etiqueta: melhoriaetiqueta: outras violações

  Evidências
  Ao navegar pelo website utilizando o teclado ou leitor de ecrã, o indicador de foco não se encontra visível em algumas componentes da página inicial e em páginas interiores, dificultando significativamente a navegação, em particular para utilizadores que dependem exclusivamente de tecnologias assistivas para interação.

  Na página inicial, durante a navegação sequencial através da tecla TAB e SHIFT+TAB, o foco não é apresentado contornando algumas componentes, sendo apenas possível inferir a sua existência através da barra de estado do navegador, o que não constitui uma solução acessível nem adequada. Por exemplo, não é percetível que o foco está nos seletores de idioma, nas hiperligações "Lista de eventos" e destaques dos eventos pois não possuem foco visível em relação a navegação com teclado. (Figura 1)

  

  Figura 1 – Exemplo de ausência de foco visível na navegação com teclado na página inicial

  O problema se repete em páginas interiores do website, por exemplo na página Lista de eventos onde a navegação por teclado deixa de ser visível nos cartões dos eventos, ou seja, as componentes não são circunscritas pelo foco. (Figura 2 e 3)

  

  Figura 2 – Exemplo de ausência de foco visível na navegação com leitor de ecrã NVDA

  

  Figura 3 – Exemplo de foco que não circunscreve os cartões dos eventos pela navegação com teclado para indicar interatividade clicável

  Sendo assim não é possível identificar visualmente a posição do utilizador em cada momento da navegação. Esta situação pode levar o utilizador a perder a noção da sua posição na página, comprometendo a usabilidade e a acessibilidade do website.

  URLs a verificar

  • https://agenda.cm-machico.pt/
  • https://agenda.cm-machico.pt/menu/lista-de-eventos
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/lista-de-eventos-cultural-e-artistico
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/lista-de-eventos-conhecimento-e-aprendizagem
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/lista-de-eventos-cartazes

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

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

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

• evidência: issue #60 Outras violações - Bugs funcionais e inconsistências de interface

  etiqueta: melhoriaetiqueta: outras violações

  Evidências:

  O website apresenta problemas funcionais (bugs) em várias páginas, impactando a usabilidade e a interação do utilizador. Por exemplo, na Página Submeter evento verifica-se a sobreposição de elementos interativos na modal de mensagens de erro. (Figuras 1 e 2)

  

  Figura 1 - Mapa interativo sobrepõe a modal na versão desktop e mobile

  

  Figura 2 - Botão “Submeter” surge sobreposto à modal (desktop e mobile)

  Na página Lista de Eventos em ecrãs de dimensões reduzidas, identificam-se vários problemas de layout e consistência. Por exemplo, as datas dos eventos (tags informativas de mês e dia) sobrepõem-se ao filtro de pesquisa e aos campos de preenchimento, durante a navegação com scroll, as datas continuam sobrepostas ao filtro. (Figuras 3)

  

  Figura 3 - Filtro de Pesquisa com tags sobrepostas em campos de preenchimento

  Além disso na versão mobile, o botão “Lista de eventos” e o breadcrumb deixam de estar disponíveis, reduzindo a consistência da navegação em relação à versão desktop.
(Figuras 4 e 5)


  

  Figura 4 - Botão “Lista de Eventos” e “Breadcrumb” disponíveis na versão desktop

  

  Figura 5 - Botão “Lista de Eventos” e “Breadcrumb” desaparecem nas versões para dispositivos móveis

  URLs a verificar

  • https://agenda.cm-machico.pt/menu/submeter-evento
  • https://agenda.cm-machico.pt/menu/lista-de-eventos
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/lista-de-eventos-desporto-e-aventura
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/lista-de-eventos-cultural-e-artistico
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/lista-de-eventos-conhecimento-e-aprendizagem
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/lista-de-eventos-cartazes

  Recomendações:
  Recomenda-se corrigir os problemas de sobreposição através de uma revisão das regras de layout, posicionamento e hierarquia visual), garantindo que modais e elementos interativos permanecem sempre visíveis e acessíveis. Adicionalmente, deve ser assegurada a consistência funcional e de navegação entre desktop e mobile, mantendo o mesmo conjunto de funcionalidades ou disponibilizando alternativas equivalentes (ex.: acesso ao breadcrumb e às ações principais).


  • É ainda importante validar o comportamento responsivo dos componentes (como filtros e etiquetas de data), garantindo que não interferem com campos de entrada nem comprometem a interação em ecrãs reduzidos.

• evidência: issue #59 Outras violações - Há conteúdos em inglês na versão portuguesa do website

  etiqueta: melhoriaetiqueta: outras violações

  Evidências:

  • Verificámos uma inconsistência linguística, uma vez que o site está em português mas há botões e conteúdos com o textos alternativos em inglês.

  


  O website apresenta nas páginas interiores da Lista de eventos mapas interativos com botões com textos alternativos duplicados e em inglês: title="Zoom in" aria-label="Zoom in" , esta implementação impacta na navegação com leitor de ecrã NVDA, e dificulta a compreensão por parte de utilizadores de língua portuguesa, idioma em que o site está disponibilizado. (Figura 1)

  

  Figura 1 - Botões "Ampliar" e "Diminuir" mapa interativo, com textos alternativos duplicados e em inglês

  Além disso, há páginas de eventos que possuem galerias de imagens que ao serem ampliadas, abrem modais com controlos de navegação (setas interativas). Esses controlos possuem textos alternativos em inglês por exemplo, aria-label="previous" e aria-label="next". Um exemplo ocorre na secção "Galeria" na imagem relativa ao Campeonato da Europa de Biatle, Triatle e Laser Run, onde os textos alternativos estão em inglês, comprometendo a acessibilidade e a consistência linguística da interface (Figuras 2).

  

  Figura 2 - Modais para controlos de imagens com controlos(setas interativas) em inglês

  A mistura de idiomas pode causar confusão aos utilizadores, afetar a compreensão da informação e constituir uma barreira à acessibilidade, especialmente para pessoas com dificuldades cognitivas, utilizadores de leitores de ecrã ou cidadãos com menor proficiência em inglês. 

  URLs a verificar

  • (Rever textos alternativos de botões em todo website. Ex: Carrosséis de imagens: Botões de controlos em inglês)
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/3564-campeonato-da-europa-de-biatle-triatle-e-laser-run
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2225-semana-gastronomica-de-machico
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2207-festival-do-atum-do-gaiado-e-do-marisco
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2204-mercado-quinhentista
  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/2203-miut-madeira-island-ultra-trail

  Recomendações:
  Recomenda‑se a uniformização do idioma de todos os conteúdos apresentados na página, garantindo que o texto se encontra integralmente em português quando o idioma principal definido é PT. Deverá ser assegurado que quaisquer termos, componentes ou conteúdos sejam devidamente traduzidos e revistos, promovendo a coerência linguística, a clareza da informação.

  • No mapa interativo é necessário remover o atributo title dos botões para "Ampliar" e "Diminuir" mapa interativo. Deve-se manter apenas o aria-label, assegurando que este contém uma descrição clara e precisa da ação e funcionalidade do botão. Esta abordagem evita a redundância de informação e reduz o ruído para utilizadores de tecnologias de apoio, como leitores de ecrã, melhorando a experiência de navegação e a acessibilidade.

• evidência: issue #57 Outras violações- Páginas com erros em links

  etiqueta: melhoriaetiqueta: outras violações

  Evidências

  • Links com erro tornam-se inacessíveis quando apresentam falhas no endereço, estão desatualizados ou levam a páginas removidas, impedindo o utilizador de aceder ao conteúdo pretendido e comprometendo a navegação e a experiência do utilizador.

  Na página Dog Trail Machico 2026, existe uma hiperligação que direciona para um formulário externo do Google, no entanto ao aceder a hiperligação o utilizador é direcionado para página com erro. (Figura 1 e 2)

  

  Figura 1 - Hiperligações com erros e conteúdo inacessível

  

  Figura 2 - Link externo com erro

  Este comportamento compromete a previsibilidade e a robustez da interação, podendo causar perda de acesso a informação e frustração na navegação para utilizadores.

  URLs a verificar

  • https://agenda.cm-machico.pt/menu/lista-de-eventos/evento/3536-dog-trail-machico-2026

  Recomendações
  Garantir a atualização e correção de todos os links, substituindo endereços inválidos ou removidos e evitando erros de navegação, desta maneira é possível assegurar que cada link permanece funcional e conduz ao conteúdo esperado.

  • Verificar o comportamento e atribuições das hiperligações, para corrigir erro associado.