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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #36 Itens de menu não estruturados em listas ul, li

  etiqueta: R 1.1etiqueta: chk 10 webetiqueta: NOK

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

  • Ver requisito 1.1 da lista 10 aspetos
    Os itens interiores do menu principal na versão mobile não estão estruturados em listas ul e li.

  

  Recomendamos a restruturação das opções interiores do menu, colocando-as dentro de elementos ul, li.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #37 Implementação desnecessária de técnicas de acessibilidade no menu

  etiqueta: R 1.2etiqueta: chk 10 webetiqueta: NOK

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

  • Ver requisito 1.2 da lista 10 aspetos

  Verificámos a utilização de técnicas de enriquecimento do menu principal com foco na acessibilidade. No entanto, identificámos que algumas dessas técnicas encontram-se incorretamente implementadas na versão desktop, uma vez que o menu do website corresponde a um menu de navegação e não a um menu de aplicação.

  • role = "none" nos elementos ul
  • role = "menuitem" nos links e nos botões

  

  Estes atributos são desnecessários, pois estamos perante um menu de navegação.
  Para além disso, o role = “none” nos elementos ul faz com que os leitores de ecrã não interpretem estes elementos como listas, o que não faz sentido em menus de navegação.
  Recomendamos a remoção dos atributos role = "none" nos elementos ul e role = "menuitem" nos links e nos botões da versão desktop do menu principal.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

  • Ver requisito 1.3 da lista 10 aspetos

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #7 Cabeçalho de nível 1 não detetado pelas tecnologias de apoio

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.1

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

  • Ver requisito 2.1 da lista 10 aspetos

  A página inicial tem um cabeçalho de nível 1 associado ao logotipo, mas esse cabeçalho não é corretamente detetado pelas tecnologias de apoio:

  

  Isso acontece porque a descrição da imagem foi colocada num atributo alt, que não é válido num ficheiro svg.
  Recomendamos a substituição do atributo alt do svg do logotipo pelos atributos role = "img" e title = "descrição da imagem", conforme o seguinte exemplo:

  <svg role = "img" title = "Município de Alcoutim">
  ...
  </svg>
  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #69 Existem textos de início de secção que não estão em cabeçalhos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

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

  Os textos de início de secção presentes nos vários acordeãos da página Cultura não estão inseridos dentro de elementos cabeçalho.

  

  O mesmo problema também ocorre no texto "Contacte-nos", que marca o início de uma secção, mas não foi colocado dentro de um elemento cabeçalho.

  

  Recomendamos que todos os textos de início de secção sejam colocados dentro de elementos cabeçalho, permitindo assim transmitir de modo estrutural informação que já é transmitida visualmente.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #9 R 3.1 - 10 Aspetos- Há tabelas com cabeçalhos que não estão marcados com o elemento <th>

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

  Notas Gerais

  • As tabelas de dados devem identificar o seu conteúdo com elementos semânticos de HTML corretos, para que os leitores de ecrã consigam referenciar corretamente os cabeçalhos e identificar a tipologia dos dados de cada coluna e linha. No caso dos cabeçalhos das tabelas, estes devem estar marcados com o elemento <th>.

  Na página Membros dos Gabinetes da Presidência e da Vereação identificamos a "Tabela da remuneração de apoio à Presidência" embora apresenta visualmente a informação de forma organizada, a sua estrutura semântica deve ser melhorada através da utilização correta de elementos de cabeçalho <th>

  Os cabeçalhos das colunas “Cargo”, “Nomeado/a”, “Remuneração Base” e “Forma de Cálculo” estão marcados com o elemento <td>, quando deveriam utilizar o elemento <th>. Esta implementação pode comprometer a interpretação correta da tabela por tecnologias de apoio. (Figura 1)

  

  Figura 1 - Tabela com cabeçalhos que não são atribuídos o <th>

  O elemento <th> é semanticamente adequado para identificar cabeçalhos e permite que tecnologias de apoio reconheçam e associem corretamente esses títulos às respetivas células de dados. Além disso, a tabela não utiliza o elemento <thead> para agrupar os cabeçalhos. A separação entre <thead> (cabeçalho) e <tbody> (conteúdo da tabela) melhora a estrutura semântica, facilita a navegação e compreensão da tabela por leitores de ecrã.

  Recomendação de melhoria
  Recomenda-se corrigir a estrutura semântica da tabela, utilizando os elementos HTML apropriados para identificar corretamente os cabeçalhos e a organização do conteúdo.

  • Corrigir um erro ortográfico no cabeçalho “Renumeração Base”, sendo o correto “Remuneração Base”.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #38 Existem campos sem etiquetas associadas

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

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

  O campo de pesquisa não tem etiqueta associada:

  

  Apesar de ter um botão na sua vizinhança que, ao ser clicado, leva o foco para o campo, existem características que não são cumpridas se não for utilizado um elemento label associado programaticamente ao campo. Por exemplo, quando se navega utilizando tab e shift+tab, os leitores de ecrã não anunciam a que se refere a caixa de texto da pesquisa, e anunciam o botão e a caixa de texto como dois elementos separados.
  Recomendamos a revisão dos formulários, de forma a garantir que todos os campos possuem etiquetas atribuídas através do elemento <label>. As etiquetas devem estar visíveis junto dos respectivos campos e corretamente associadas, assegurando que os atributos for da etiqueta e id do campo correspondente são iguais (associação explícita), ou que o campo e o texto dda etiqueta são colocados dentro do elemento <label> (associação implícita.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #17 Imagens decorativas com texto alternativo incorreto

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

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

  Notas Gerais

  • As imagens decorativas não acrescentam informação ao conteúdo da página, geralmente estão acompanhadas de uma descrição textual ou servem para tornar a página mais apelativa. Estas imagens podem conter um texto alternativo nulo (alt=””) no HTML, ou estarem apenas como background-image em CSS.

  Na homepage, na secção “Notícias” e “Agenda” existem cards com imagem e títulos sobre as respetivas notícias e eventos. Observamos que as imagens possuem texto alternativo redundante, pois possuem o mesmo texto alternativo que os títulos dos cards. Consequentemente os leitores de ecrã, fazem uma leitura duplicada da informação (Figura 1). 

  

  Figura 1 - Cards das "Notícias" com texto alternativo incorreto

  O mesmo acontece em outros cards das páginas interiores, por exemplo em Descobrir Alcoutim, com duplicação de informação para utilizadores com leitores de ecrã. Por exemplo, o título "Posto de Turismo" possui imagem com texto alternativo "Imagem - Posto de Turismo". (Figura 2)

  

  Figura 2 - Cards com imagens da página "Descobrir Alcoutim" com textos alternativos incorretos e redundantes com seus títulos

  É necessário rever todo o website pois existe o mesmo problema em outras páginas interiores, que possuem imagens decorativas com textos alternativos que causam ruídos para utilizadores das tecnologias de apoio. Por exemplo:

  • Agenda de eventos
  • Juntas de Freguesia
  • Águas e Resíduos

  Recomendação de melhoria

  Para evitar que o leitor de ecrã repita várias vezes a mesma informação, e reduzir ruídos de informações para utilizadores com leitores de ecrã, as imagens dos cards devem ser consideradas como decorativas e colocado o texto alternativo nulo da seguinte forma: (alt=””).

  Outra solução é adicionar as imagens via CSS. Para esta situação, deve-se também utilizar a técnica do link esticado, garantindo assim que o leitor de ecrã lê a informação relevante apenas uma vez.

• evidência: issue #16 Imagens com textos alternativos incorretos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

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

  Notas Gerais

  • As imagens informativas devem incluir um texto alternativo que sirva de síntese do seu conteúdo e que seja lido pelo leitor de ecrã.
  • As imagens não decorativas deverão ter uma descrição breve associada, nomeadamente através do uso do atributo . Esta legenda deve descrever fielmente o propósito da imagem no contexto em que se encontra.

  A página inicial do website, apresenta um carrossel imagens destaques que possuem texto alternativo incorreto. Com aria-label="1 / 4", aria-label="2 / 4", aria-label="3 / 4" e aria-label="4 / 4". Estas descrições confundem utilizadores no primeiro contacto com as interações do carrossel. Pois o leitor de ecrã não informa sobre o conteúdo das imagens, e anuncia apenas os texto: “1/4 2/4 3/4 4/4”. (Figura 1)

  

  Figura 1- Imagens do carrossel não possuem texto alternativo correto

  Além disso, no rodapé da página inicial existe uma imagem em formato SVG sem texto alternativo e marcada com aria-hidden="true". Como consequência, o leitor de ecrã ignora completamente este elemento, impedindo o acesso à informação visual nele contida. Assim, a indicação de que o município possui o “Selo ODSLocal Dinâmica Municipal 2025” torna‑se inacessível para utilizadores de tecnologias de apoio. (Figura 2)

  

  Figura 2- Imagem do "Selo ODSLocal" não possui texto alternativo e não é identificada por tecnologias de apoio

  Páginas interiores, possuem imagens que apresentam-se como cartão visita de pontos de interesse do Município e não possuem textos alternativos. Por exemplo, a categoria "Onde Comer" na página Beira Rio - Cafetaria e Tapas existe uma imagem apenas com um alt no código HTML, sem texto alternativo que descreva a imagem. (Figura 1)

  

  Figura 3- Imagem sem texto alternativo em ponto de interesse do Município

  Recomendações
  Recomendamos a revisão das imagens não decorativas para que incluam um texto alternativo, através do elemento (alt=”Incluir descrição do conteúdo da imagem”). Desta maneira será possível informar utilizadores das tecnologias de apoio sobre a existência das imagens, com textos que descrevam o conteúdo da imagem de forma sucinta.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #20 Representações gráficas inacessíveis em ficheiros PDF

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.2

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

  Notas Gerais

  • A imagem complexa deve ser acompanhada não só de uma descrição curta, colocada como texto alternativo da imagem, mas também de uma descrição detalhada longa sobre o seu conteúdo, que deve ser colocada à parte e não como texto alternativo desse elemento.
  • Podemos considerar neste critério elementos como gráficos, diagramas, mapas, imagens, infografias, entre outros. Podemos considerar neste critério elementos como gráficos, diagramas, mapas, imagens, infografias, entre outros.

  A página Publicações apresenta diversos conteúdos informativos disponíveis em ficheiros PDF. Incluindo o Boletim Municipal, Comunicar Alcoutim, folhetos de museus e outros materiais informativos. Muitos destes ficheiros incluem imagens, mapas, esquemas visuais, infográficos e programas de atividades que não possuem descrições alternativas.

  Por exemplo, no Folheto do Museu do Rio, observam‑se elementos gráficos essenciais (mapas do percurso do rio, ilustrações, composições fotográficas e informação visual estruturada) que não são acompanhados de texto alternativo ou descrição equivalente, impossibilitando a interpretação por utilizadores de leitores de ecrã ou outras tecnologias de apoio. (Figura 1)

  

  Figura 1 - Folheto Museu do Rio Alcoutim com Mapa do rio sem descrição alternativa

  Outras páginas com o mesmo problema:

  • Agenda Março
  • Boletim Municipal
  • Folheto Arte Sacra - Francês
  • Percurso Pedestre das Laranjeiras
  • Alcoutim Aldeia Fronteiriça -Ficheiro em francês
  • GUIA Bilingue Alcoutim

  Estes documentos PDF, não possuem texto alternativo para imagens relevantes, utilizam elementos visuais para transmitir informação essencial, podem apresentar estruturação inadequada quando convertidos para texto. Os conteúdos tornam‑se inacessíveis a pessoas com deficiência visual, comprometendo o cumprimento do presente requisito e dificultando a compreensão da informação disponibilizada pelo Município.


  Recomendações
  Recomendamos a revisão das páginas do site, de forma a garantir que os conteúdos dos ficheiros PDF sejam acessíveis para todos utilizadores.

  • Fornecer versões alternativas acessíveis como textos alternativos significativos a todas as imagens
  • Disponibilizar uma versão HTML, por exemplo para mapas e gráficos
  • Incluir descrições longas para elementos visuais complexos para informar sobre dados relevantes das representações gráficas, como calendários de atividades e infográficos;

• evidência: issue #19 Mapa interativo sem texto alternativo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.2

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

  Notas gerais

  • Gráficos resultantes de análise de dados deverão ser acompanhados da tabela de dados que lhe deu origem, de forma a preservar o acesso à informação completa. Gráficos resultantes de análise de dados deverão ser acompanhados da tabela de dados que lhe deu origem, de forma a preservar o acesso à informação completa.

  O Mapa do site, possui mapa interativo que não possui título, texto alternativo ou descrição longa que descreva sua existência e região em foco, neste caso o "Mapa Turístico de Alcoutim". Como consequência, utilizadores de leitores de ecrã não conseguem identificar aceder aos pontos de interesse apresentados no mapa. (Figura 1)

  

  Figura 1 - Mapa interativo sem texto alternativo

  Além disso, existem interações com ícones que são assinalados de forma visual no mapa. E criam-se marcadores em pontos de interesse com pins, de acordo com as categorias selecionadas no menu lateral. No entanto, esses marcadores possuem textos alternativos incorretos. Por exemplo ao selecionar a categoria "Hotel" o texto alternativo está incorreto alt="Hotel d" (Figura 2)

  

  Figura 2 - Imagens dos marcadores no mapa interativo com textos alternativos incorretos

  O mesmo acontece em mapas disponíveis nas páginas interiores do website:

  • https://www.cm-alcoutim.pt/pois/cafe-rosa
  • https://www.cm-alcoutim.pt/pois/beira-rio-cafetaria-e-tapas
  • https://www.cm-alcoutim.pt/pois/bh-restaurante-e-snack-bar

  Recomendação de melhoria:
  Rever todos os elementos visuais do website, assegurando que o mapa interativo e os marcadores possuem textos alternativos corretos, completos e coerentes com a função de cada elemento para que utilizadores de tecnologias de apoio possam perceber a existência do mapa e aceder aos pontos de interesse apresentados.

  • O mapa deve incluir identificação acessível (título, texto alternativo ou descrição longa), e os pins devem descrever adequadamente os pontos de interesse representados.
  • Sugestão de texto alternativo para o mapa interativo: "Mapa Turístico de Alcoutim (versão interativa)”.

• evidência: issue #18 Imagens complexas sem textos alternativos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.2

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

  Notas gerais

  • A imagem complexa deve ser acompanhada não só de uma descrição curta, colocada como texto alternativo da imagem, mas também de uma descrição detalhada sobre o seu conteúdo, que represente de forma textual a informação mais relevante.
  • Gráficos resultantes de análise de dados deverão ser acompanhados da tabela de dados que lhe deu origem, de forma a preservar o acesso à informação completa.

  Calendário em formato de imagem sem texto alternativo

  Na página Aviso - Calendarização da Unidade de Saúde Móvel (USM) (março2026) , foi identificada uma imagem complexa com conteúdo informativo sobre o programa de atividades para o mês de março. Cujo texto alternativo está incorreto e insuficiente com alt="USM Alcoutim MAR2026prop nova". Este texto não descreve o conteúdo nem a função da imagem, impedindo que utilizadores de leitores de ecrã acedam à informação transmitida visualmente. (Figura 1)

  

  Figura 1 - Imagem complexa com calendarização de atividades não acessíveis para utilizadores com leitores de ecrã

  Recomendações

  • Substituir o texto alternativo atual da imagens por uma descrição adequada como uma síntese do conteúdo da imagem.
  • Incluir uma descrição longa detalhada num texto adjacente e próximo a imagem complexa. Incluindo o cronograma, informações sobre as consultas e as notas sobre marcações e contactos.

  Organograma em PDF (NOK)

  A página Organograma disponibiliza um ficheiro PDF contendo o Organograma Câmara Municipal De Alcoutim.

  No entanto, o organograma apresentado é inacessível, uma vez que não possui conteúdo alternativo que descreva, de forma textual em uma descrição longa, estruturada e equivalente a informação representada no fluxograma. Esta prática impede que utilizadores de tecnologias de apoio, nomeadamente leitores de ecrã compreendam a hierarquia e a organização interna dos serviços municipais. (Figura 2)

  

  Figura 2 - Conteúdo do organograma apresenta-se de maneira desordenada para leitores de ecrã

  Apesar de ser possível navegar pelo PDF com leitor de ecrã, a ordem lógica da informação não corresponde à apresentada visualmente, o que reforça as barreiras de acessibilidade e compromete a perceção correta da estrutura organizacional.

  Outras páginas com o mesmo problema:

  • Gráfico sem descrição longa ou tabela complementar associada https://www.cm-alcoutim.pt/municipio/o-concelho/demografica-do-concelho-de-alcoutim
  • Imagem com mapa estático, sem descrição e sem nenhuma menção sobre sua existência no texto https://cm-alcoutim.pt/descobrir-alcoutim/como-chegar

  Recomendações

  Recomendamos que o conteúdo do organograma seja disponibilizado numa página estruturada em HTML e que inclua uma descrição longa e detalhada, apresentando de forma clara a divisão dos departamentos e respetivas hierarquias, garantindo assim o acesso equitativo à informação. Caso utilizem imagens para o organograma, é necessário garantir que o texto alternativo (alt=””) tenha um sumário breve e faça uma síntese sobre o objetivo da representação gráfica. Nos gráficos, disponibilizar sempre a tabela de dados correspondente para garantir acesso integral à informação.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #21 Imagens-link com textos alternativos incorretos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

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

  Logotipo com texto alternativo incorreto

  O logotipo do Município apresenta-se como uma imagem-link nas páginas interiores, no entanto seu texto alternativo está incorreto com title="Homepage" em inglês. (Figura 1)

  

  Figura 1 - Logotipo nas páginas interiores com texto alternativo incorreto

  Além disso, o logotipo nas páginas interiores tem a função de retornar à página inicial. No entanto, o texto alternativo não indica esta informação, sendo assim utilizadores podem não perceber que é possível utilizar este elemento para retornar a página inicial.

  Recomendação de melhoria

  Recomendamos corrigir o texto alternativo da imagem para que descreva corretamente o logotipo. Sugestão de textos alternativos:

  • O texto alternativo deve corresponder à língua do site em questão.
  • Nas páginas interiores, incluir no logotipo, um title no link para informar sobre o retorno a página principal do website, title = “Voltar à página inicial do Município de Alcoutim”

  Imagens-link das redes sociais com texto alternativo incorreto

  O website possui no header as imagens-link das redes sociais, com textos alternativos incorretos por exemplo alt="Imagem - Youtube" e title = “Youtube”, estes textos não descrevem adequadamente o contéudo da imagem-link e o destino da ligação para a página externa. (Figura 2)

  

  Figura 2 - Imagens -link das redes sociais no header com textos que não indicam redirecionamento para páginas externas

  Esta prática prejudica a perceção da funcionalidade das imagens-link por utilizadores de leitores de ecrã e viola o presente requisito.

  O mesmo acontece com as imagens-link do rodapé que direcionam para os sites externos:
  alt="logotipo Algarve21" ; alt="logotipo Uniao Europeia" , alt="logotipo livro de Reclamações", alt="logotipo w3c" e alt="logotipo Autarquia360", é necessário corrigi-las. (Figura 3)

  

  Figura 3- Imagens -link do rodapé com textos que não indicam redirecionamento para páginas externas

  Recomendação de melhoria


  É necessário ajustar os textos alternativos da imagens‑links para refletir claramente o propósito e o destino dos links. Por exemplo: alt="Youtube" pois descreve o logotipo da rede social. E o title= “Ir para página do Youtube” atribuído ao link que informa sobre o redirecionamento do link para uma nova página.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #63 Existem vídeos sem legendas fechadas

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 7.2

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

  Existem vídeos no site com legendas automáticas, que podem não refletir com exatidão o conteúdo que é anunciado. Exemplo disso são os vídeos presentes na secção Multimédia da página inicial:

  

  Recomendamos que seja incluída uma legenda fechada para cada vídeo, caso a legenda gerada automaticamente esteja boa ela pode ser reaproveitada para gerar uma nova transcrição do conteúdo. Os vídeos que visualmente transmitem uma informação para o utilizador que não é transmitida em áudio devem verificar a necessidade de incluir também uma audiodescrição.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #61 Não é possível saber quais os dias do calendário que têm eventos

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  O Calendário presente na secção “Agenda” da página inicial não transmite aos leitores de ecrã em que dias existem eventos, sendo essa informação transmitida apenas por meios visuais:

  

  Recomendamos que, em cada dia com eventos, seja transmitido às tecnologias de apoio esse facto. Essa informação pode ser acrescentada, por exemplo, ao atributo aria-label dos botões, da seguinte forma:
  aria-label="sexta-feira, 3 de abril de 2026, tem eventos".

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  O carrossel presente na secção Multimédia da página inicial apresenta o número total de elementos aos leitores de ecrã, em vez de apresentar apenas os elementos visíveis no ecrã:

  

  Para além disso, são apresentados elementos duplicados aos leitores de ecrã.
  Por exemplo: o elemento descrito como “1 / 12” (Festival do Contrabando 2019) aparecem também como elemento descrito como “7 / 12”; o elemento descrito como “2 / 12” aparece também como elemento “8 / 12”, e assim por diante. Assim, são mostrados 12 elementos às tecnologias de apoio, quando o número de elementos é 6.
  Por último, destacamos que o foco fica "preso" nos itens do carrossel presente na secção "Próximos eventos": se tentarmos navegar por todos os elementos da página utilizando a tecla tab, verificamos que o foco chega até aos itens do carrossel referido, mas a navegação continua em círculo pelos elementos deste carrossel, não sendo possível passar para o próximo item fora desta estrutura.

  Recomendamos que os carrosséis do site sejam restruturados de forma a que o número de elementos apresentados aos leitores de ecrã seja igual ao número de elementos visíveis, e os elementos apresentados visualmente sejam os mesmos que os leitores de ecrã percecionam. Tal restruturação vai implicar necessariamente a remoção dos itens duplicados que estão a ser mostrados às tecnologias de apoio.
  Recomendamos ainda que seja eliminada a circularidade por elementos dos carrosséis ou outras estruturas, de forma a que seja possível passar por todos os controlos da página utilizando a navegação por teclado.

• evidência: issue #58 Existem acordeãos estruturados incorretamente

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Os acordeãos presentes na página Cultura estão estruturados incorretamente.

  

  Os acordeãos foram estruturados como se de um tabulador se tratasse, com role = “tab” nos títulos e role = “tabpanel” nos painéis de conteúdo, sendo por isso transmitda às tecnologias de apoio a informação de que cada título é um separador, quando não é.
  Recomendamos a restruturação dos acordeãos do site da seguinte forma:

  • Os atributos role = “tab” devem ser removidos Os divs que contêm os spans com o texto dos títulos. Se não for possível substituir esses elementos div por elementos button (botões nativos), deve ser colocado um role com o valor “button” em cada um deles. No entanto, caso pretendam manter os elementos div, devemos alertar para o facto de os mesmos não terem os mecanismos de acessibilidade dos botões nativos, pelo que devem manter o atributo tabindex com o valor 0 em cada um deles, para que sejam focáveis via teclado;
  • Os atributos role = “tabpanel” devem ser removidos dos elementos que contêm o conteúdo de cada painel de acordeão;
  • Os textos descritivos dos botões dos acordeãos são considerados títulos de secção, pelo que os botões devem ser colocados em elementos cabeçalho de nível 2, no caso do exemplo acima descrito.

  Para obtenção de informação mais detalhada acerca da construção correta de acordeãos, recomendamos a consulta de um exemplo de acordeon na página do W3C.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk conteúdoetiqueta: R 1.1etiqueta: NOK

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

  Não existe qualquer resumo do propósito na página inicial do Município de Alcoutim, pelo que deve ser adicionado:

  

  Não existe um breve resumo sobre o propósito do site Município de Alcoutim

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

  

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

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #53 Inexistência de termos complexos

  etiqueta: chk conteúdoetiqueta: R 1.2etiqueta: N/A

  Os termos mais complexos têm uma definição agregada.
  – ver requisito 1.2 na lista Conteúdo
  Não encontrámos termos complexos no site, pelo que o requisito não se aplica.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #24 R 2.1 - Conteúdo -O texto tem tamanho acima do recomendado (12pt, equivalente a 16px)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 2.1

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

  Notas Gerais

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

  O website possui informações primárias com tamanho inferior a 12pontos(16px) por exemplo na página inicial, as opções de segundo nível do menu. (Figura 1)

  

  Figura 1 - Demonstração da fonte do menu principal com tamanho inferior ao recomendado.

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

  Na página Como Chegar, os textos do breadcrumb: “Página inicial”, “Descobrir Alcoutim”, “Como chegar” apresentam-se compridos pelo header. Além disso, ao alterar para uma resolução mais pequena (mobile/tablet, por exemplo), os textos visíveis ficam com um tamanho muito pequeno. (Figura 2)

  

  Figura 2- Demonstração do breadcrumb com tamanho pouco escalável na versão mobile

  Recomendação de melhoria

  • É necessário ser corrigido os textos de informações primárias, para um tamanho igual ou superior ao recomendado.
  • As páginas deverão ser revistas para garantir que todo o conteúdo se adapta a diferentes resoluções de ecrã.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #57 Os documentos longos não têm um índice no topo

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 4.1

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

  Notas gerais

  • Para facilitar a navegação em páginas longas, com várias secções de conteúdos, deve existir um índice no topo da página. Esse índice deve conter hiperligações para as várias seções que existem.
  • O uso de acordeões como substituição de um índice é uma solução válida, mas é importante ter em consideração alguns aspetos essenciais para garantir a acessibilidade. A estrutura do acordeão deve ser construída de forma adequada, assegurando que funcione sem problemas para todos os utilizadores, incluindo aqueles que utilizam tecnologias de apoio.

  Não existe um índice no topo de uma página longa

  Nas páginas consideradas longas, não existem um índice com hiperligações para cada secção interna dessa página. (Figura 1)

  

  Figura 1- Página longa, Breve Resumo Histórico sem índice no topo

  Outras páginas longas sem índice no topo:

  • https://cm-alcoutim.pt/descobrir-alcoutim/o-que-visitar/navegar-e-preciso-o-silencio-das-mares
  • https://cm-alcoutim.pt/municipio/projetos-financiados/cresc-algarve-2020-programa-operacional-do-algarve

  Recomendações
  Adicionar um índice com hiperligações para cada secção interna.

  O índice está a ser substituído por acordeões que não estão estruturados corretamente

  No website, existem acordeões que não estão estruturados corretamente e que devem ser corrigidos (Figura 2).

  

  Figura 2- Página Cultura com exemplo de acordeão mal estruturado como div

  Outros exemplos de páginas com acordeões mal estruturados:

  • https://cm-alcoutim.pt/municipio/o-concelho/breve-resumo-historico
  • https://cm-alcoutim.pt/descobrir-alcoutim/produtos-locais-de-qualidade
  • https://cm-alcoutim.pt/areas-de-atuacao/accao-social-e-saude/bolsas-de-estudo

  Recomendações

  Recomendamos rever os acordeões do website para garantir que sejam estruturados corretamente. Para isso, recomendamos consultarem as notas partilhadas no critério 8.3 da checklist dos 10 aspectos.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #31 Existem elementos interativos acionados apenas com a passagem do rato (hover)

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.1

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

  Verificou-se que no website existem elementos interativos ativados apenas com a passagem do rato (hover).

  Na página inicial, a secção "Agenda" possui um calendário que apresenta pop-ups informativos em suas datas, com uma lista dos eventos associados as datas selecionadas. Por exemplo, ao passar o rato no dia 7 de março, o pop-up é apresentado visualmente através de interações de hover, sem que exista uma relação semântica adequada com o elemento do dia correspondente. (Figura 1)

  

  Figura 1- Pop-up do calendário é ativado apenas com hover

  Estes conteúdos não recebem foco, não estão associados através de atributos ARIA (por exemplo aria-describedby, aria-controls ou aria-haspopup) e não são anunciados pelo leitor de ecrã. Como resultado, os utilizadores de tecnologias de apoio não conseguem perceber que existem eventos associados a uma determinada data nem aceder à lista desses eventos.
  Esta implementação cria uma barreira de acesso à informação, uma vez que os eventos são apresentados apenas de forma visual e não estão corretamente expostos na árvore de acessibilidade.

  Além disso, ainda na página inicial existem elementos como imagens e botões que são acionados apenas com a passagem do rato (hover). Por exemplo, imagens da secção “Avisos e Informações” (Figura 2)

  

  Figura 2- Imagens são alteradas através da passagem do rato (hover)

  Assim como, o botão “Saber mais” da secção “Publicações” só estão disponíveis com hover. (Figura 3)

  

  Figura 3- Botões disponíveis apenas através da passagem do rato (hover)

  Esta problemática, impacta utilizadores com tecnologias de apoio que não percebem o comportamento dos elementos ativados apenas com o rato, e também impacta utilizadores dos dispositivos móveis com interação por toque. Pois o botão não é visível, por exemplo (Figura 4)

  

  Figura 4- Botão "Saber mais" indisponível na versão para dispositivos móveis com interação por toque

  Recomendações de melhorias

  Os eventos associados a cada data devem ser semanticamente ligados ao botão do respetivo dia, utilizando mecanismos apropriados de acessibilidade, como aria-describedby ou aria-controls, garantindo que o leitor de ecrã anuncie a existência de eventos ao focar a data correspondente. Caso seja utilizado um painel ou pop-up com a lista de eventos, este deve ser acessível por teclado, poder receber foco e possuir papéis ARIA adequados.

  • É necessário assegurar que os conteúdos atualmente exibidos apenas por hover também possam ser ativados através do foco do teclado, garantindo que os utilizadores que não utilizam rato consigam aceder à mesma informação promovendo uma experiência mais inclusiva e alinhada com as boas práticas.

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

Lista de evidências recolhidas:

• evidência: issue #32 Ícones com dimensões inferiores à área clicável recomendada (Melhoria)

  etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: R 5.2

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

  As áreas clicáveis de elementos interativos possuem a dimensão mínima recomendada. No entanto, existem ícones que não possuem um tamanho mínimo visível.

  Por exemplo na página inicial no carrossel de imagens destaques no banner, os ícones das setas interativas “Slide Anterior” e “Próximo Slide” possuem dimensões inferiores ao tamanho recomendado, ficando demasiado pequenas em dispositivos móveis. (Figura 1)

  

  Figura 1- Ícones das setas interativas do carrossel de imagens com tamanho inferior a área clicável

  Assim como os ícones das redes sociais no rodapé do website. (Figura 2)



  

  Figura 2- Ícones das redes sociais com tamanho inferior a área clicável

  Na secção “Partilhar” das páginas inferiores, os ícones das redes sociais também apresentam-se com tamanho visível inferior ao recomendado, por exemplo na página Acção Social.

  Recomendação de melhoria
  Recomenda‑se aumentar o tamanho visível dos ícones para garantir melhor perceção e usabilidade.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

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

  Notas Gerais

  • Os elementos gráficos clicáveis devem ser percecionáveis como tal, através da forma, da cor ou do aparente volume.

  A análise revela na Área reservada do website existem elementos interativos que não possuem contraste suficiente. Como por exemplo, os ícones * que indicam campos de preenchimento obrigatório e o ícone para ocultar a palavra-passe. Com taxa de contraste (2:1) valor inferior ao mínimo recomendado. (Figura 1)

  

  Figura 1 - "Área reservada" com elementos interativos e ícones com problemas de contraste

  Esta prática, dificulta utilizadores com baixa visão reconhecer elementos clicáveis. O mesmo acontece nos elementos interativos da página Áreas de Atuação com as setas podem ser pouco visíveis para utilizadores com baixa visão. (Figura 2)

  

  Figura 2- Setas interativas dos cards com problemas de contraste

  Recomendação de melhoria
  É necessário rever componentes em todas as páginas do website. E corrigir a combinação de cores que não passam na avaliação de contraste. Além dos exemplos apresentados na auditoria, é necessário rever o contraste de todos os componentes de maneira transversal para o cumprimento das boas práticas de acessibilidade em todo website.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #48 Inexistência de formulários com mais de dois ecrãs de altura

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

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

  Não encontrámos formulários com mais de dois ecrãs de altura, pelo que o requisito não se aplica.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #47 Inexistência de formulários com mais de uma página

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

  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

  Não encontrámos formulários com mais de uma página, pelo que o requisito não se aplica.

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

Lista de evidências recolhidas:

• evidência: issue #70 Não existem restrições do número de caracteres a inserir nos campos

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

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

  Notas Gerais

  • Os campos de formulário, que têm um limite máximo de números (ex: número de telefone, código postal…), devem limitar a quantidade de caracteres a inserir. Desta forma, garantimos que não são inseridos mais caracteres do que o necessário, evitando possíveis erros.
  • Os campos de formulário que aceitam caracteres específicos, por exemplo, apenas números ou apenas letras, devem impedir a inserção de determinados tipos de caracteres. Desta forma, garantimos que não são inseridos caracteres errados, evitando possíveis erros.

  Formulários (Melhoria)

  Na página do formulário Área Reservada, verificou-se que é possível inserir nos campos "Email" e "Palavra-passe" mais caracteres do que é necessário para o tipo de input, ou seja o número de caracteres de input é ilimitado. (Figura 1)

  

  Figura 1 - Campos sem restrição da área de preenchimento

  O mesmo acontece nos formulários da Agenda e Pesquisa:

  • https://cm-alcoutim.pt/agenda?amount=12&page=1
  • https://cm-alcoutim.pt/pesquisa?searchTerm=not%C3%ADcias

  Recomendações
  Recomendamos a revisão dos campos de escrita para limitar o número máximo de caracteres que é possível inserir, consoante o tipo de campo.

  Formulário Conctacte-nos (OK)

  Neste formulário o critério está a cumprir (Figura 1):

  

  Figura 1 - Formulário Contacte-nos com campos de preenchimento que refletem o tamanho previsível dos dados.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #46 Inexistência de formulários que apresentem revelação progressiva

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

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

  Não encontrámos formulários que apresentem revelação progressiva, pelo que o requisito não se aplica.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #49 Existem campos sem etiquetas associadas

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

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

  O campo de pesquisa não tem etiqueta associada.

  

  Apesar de ter um botão na sua vizinhança que, ao ser clicado, leva o foco para o campo, existem características que não são cumpridas se não for utilizado um elemento label associado programaticamente ao campo. Por exemplo, quando se navega utilizando tab e shift+tab, os leitores de ecrã não anunciam a que se refere a caixa de texto da pesquisa, e anunciam o botão e a caixa de texto como dois elementos separados.
  Recomendamos a revisão dos formulários, de forma a garantir que todos os campos possuem etiquetas atribuídas através do elemento <label>. As etiquetas devem estar visíveis junto dos respectivos campos e corretamente associadas, assegurando que os atributos for da etiqueta e id do campo correspondente são iguais (associação explícita), ou que o campo e o texto dda etiqueta são colocados dentro do elemento <label> (associação implícita.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #44 Inexistência de formulários com ações longas

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

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

  Não existem formulários com ações longas, pelo que o requisito não se aplica.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #51 Inexistência de mensagem de sucesso da transação

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

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

  Não é apresentada uma mensagem de sucesso após a submissão do formulário da secção “Contacte-nos” da página inicial.

  

  Página após submissão do formulário sem mensagem de sucesso

  Recomendamos que todos os formulários apresentem uma mensagem a comunicar o sucesso da transação, e que essa mensagem seja lida automaticamente pelos leitores de ecrã.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

  Não identificamos 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 #41 Existência de mensagens de erro nem sempre visíveis

  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

  As mensagens de erro apresentadas no formulário da secção “Contacte-nos” da página inicial não estão sempre visíveis:

  

  Mensagem de erro relativa ao campo email quando o mesmo não está focado

  

  Ausência de mensagem de erro relativa ao campo email quando o mesmo está focado

  Como se pode observar nas figuras, a mensagem de erro relativa ao campo email só aparece quando este campo não está focado, ocorrendo o mesmo para os outros campos.
  Para além disso, apesar de estar a ser efetuada a associação programática das mensagens de erro aos respetivos campos, as mensagens não estão a ser anunciadas pelo leitor de ecrã, dado que são ocultadas para estas tecnologias quando os campos são focados. Acresce que a associação programática foi feita parcialmente, pois é também necessário incluir o atributo aria-invalid em cada campo com erro de preenchimento.

  

  Mensagem de erro parcialmente associada ao campo email

  Recomendamos que as mensagens de erro apareçam mesmo que os respetivos campos estejam focados, e que a única condição que as torne invisíveis seja o correto preenchimento dos respetivos campos e não o facto de o foco estar ou não em cada campo.
  Recomendamos ainda que seja usado o atributo aria-invalid quando os campos apresentam mensagem de erro, de forma a completar a associação programática.

etiqueta: NOK

Lista de evidências recolhidas:

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

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

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

  A mensagem de erro “Use um email válido, por favor” presente no formulário da secção “Contacte-nos” da página inicial não ajuda no preenchimento do campo.

  

  Como observado na figura, a mensagem “Use um email válido, por favor” que é apresentada quando o campo foi preenchido com um formato incorreto não indica qual o formato a ser inserido, não ajudando a preencher o campo.
  Recomendamos rever todos os formulários do website para garantir que a mensagem de erro apresentada explique para o utilizador como preencher os campos corretamente.

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

Lista de evidências recolhidas:

• evidência: issue #73 Outras violações - Existem campos de formulários onde não é possível escrever

  etiqueta: outras violaçõesetiqueta: melhoria

  Não é possível escrever nos campos "O seu nome", "O seu Email" e "Contacto telefónico" do formulário "Contacte-nos" da página inicial.

  

  Recomendamos que estes campos permitam a escrita dos dados a que se destinam.