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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Não é possível abrir as subopções do menu com o teclado ou leitor de ecrã

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

  Quando tentamos abrir as subopções do menu utilizando o teclado ou um leitor de ecrã, apesar de existir um indicativo visual de que o menu foi aberto, as subopções não são apresentadas:

  

  Com o teclado é possível ver a mudança do indicativo visual, no entanto, as subopções não estão visíveis

  

  Com o leitor de ecrã não é possível identificar que as subopções estão fechadas (comprimido)

  

  Com o leitor de ecrã não é possível abrir as subopções e identificar que as subopções estão abertas (expandido)

  Devem garantir o correto funcionamento do menu com o leitor de ecrã e teclado, para isso devem garantir:

  Navegação com o teclado:

  • Deve ser possível navegar por todos os links e subopções com o TAB + SHIFT TAB
  • Deve ser possível abrir as subopções com a tecla ENTER e Espaço

  Navegação com o leitor de ecrã:

  • Deve ser possível navegar por todos os links e subopções com o TAB + SHIFT TAB e por elementos (Voice Over: VO + seta p/ esquerda ou direita | NVDA: seta p/ baixo ou cima)
  • Deve ser possível abrir as subopções (Voice Over: VO + Espaço | NVDA: enter e espaço)

  No menu compacto, é possível identificar problemas na navegação pelas subopções do menu. Para uma opção existem duas subopções:

  

  A opção município possui a seta (>) e um círculo para aceder as subopções

  Quando abrimos as subopções com o leitor de ecrã, o seu foco permanece nas opções anteriores:

  

  Ao abrir uma subopção, o foco do leitor de ecrã se mantém na subopção

  No menu compacto, recomendamos que este seja acessível através do teclado e do leitor de ecrã. Para tal, é necessário eliminar a duplicidade de acesso às subopções e garantir que o foco do leitor de ecrã se mantenha sempre no conteúdo visível.

  No menu desktop partilhamos a construção do menu via codepen que pode ajudar: https://codepen.io/vic-msa/pen/WbQzwRg

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

  É 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

  Nas resoluções mobile e tablet não é possível aceder ao menu com o teclado ou leitor de ecrã:

  

  Depois de idioma, o foco salta para as redes sociais ao invés do menu

  Recomendamos rever o menu compacto para garantir que seja possível abri-lo com o teclado e leitor de ecrã.

• evidência: Não é possível navegar para a opção seguinte do menu sem percorrer as subopções

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 1.2

  É 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

  As opções do menu não devem abrir automaticamente quando recebem o foco através das tecnologias de apoio ou do teclado. Este comportamento faz com que os utilizadores tenham que percorrer todas as subopções antes de conseguirem avançar para a próxima opção do menu. Por exemplo, quando navegamos pelo menu utilizando o teclado, não conseguimos aceder as subopções de "Participar" sem antes percorrer por todas as subopções de "Município" e "Diretório de Serviços".

  

  É necessário percorrer todas as subopções antes de aceder a opção "Participar" do menu

  Recomendamos que as opções de 2º nível do menu fiquem fechadas até o utilizador escolher aceder às subopções. Para isso, é necessário criar um evento no Javascript que gerencie a abertura e fecho das opções do menu pelo atributo aria-expanded.

  Para mais informações partilhamos também um exemplo de construção do menu da W3C.

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 1.2

  É 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 são redundantes e outras encontram-se incorretamente implementadas, uma vez que correspondem a menus de aplicação e não a menus de navegação, como é o caso do menu do website.

  

  Figura 1 - Menu principal

  Como se pode observar na figura:

  • Os elementos <ul> do menu principal foram enriquecidos com o atributo role= "menu";
  • Os elementos <li> do menu principal foram enriquecidos com o atributo role= "none";
  • Os elementos <a> dentro dos elementos <li> do menu principal foram enriquecidos com os atributos role= "menuitem", aria-haspopup="menu" e aria-expanded="false" (valor por omissão).
    Sendo este um menu de navegação (não de aplicação), a utilização da maior parte destes atributos é desnecessária.
    O único atributo com relevância neste tipo de menus é o aria-expanded presente nos elementos <a>, mas verificámos que o seu valor não é atualizado quando um item de menu é expandido ou recolhido.
    Verificámos ainda que o comportamento de navegação com as setas direcionais é inconsistente.
    Recomendamos a eliminação dos atributos role= "menu" dos elementos <ul>, role= "none" dos elementos <li> e role= "menuitem" e aria-haspopup="menu" dos elementos <a>.
    Recomendamos ainda que o comportamento dos atributos aria-expanded seja desenvolvido, de modo a que o seu valor seja atualizado ao expandir e recolher cada item de menu, passando assim essa informação às tecnologias de apoio.
    Partilhamos um exemplo de construção do menu no Codepen, com as principais características de uma menu de navegação acessível.

• evidência: As opções do menu não apresentam uma indicação visual de que contêm subopções

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 1.2

  É 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

  As opções do menu devem apresentar uma indicação visual para informar que contêm subopções. Isso permite que as pessoas que navegam com teclado e leitor de ecrã, e que utilizam a visão ou parcial, identifiquem de forma clara as opções disponíveis.

  Embora o menu do website tenha uma sinalética apresentado no menu pelo círculo (●), essa sinalética não possui o objetivo de indicar quais opções contém subopções.

  

  Opções do menu não contém uma sinalética visual que indica que contém subopções

  Recomendamos indicar visualmente quais opções do menu contém subopções. Para isso, podem incluir uma sinalética visual, como por exemplo, uma seta para baixo quando o menu estiver fechado, e seta para cima quando o menu estiver aberto.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: Não existem imagens-link no menu

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

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

  • Ver requisito 1.3 da lista 10 aspetos

  Não identificamos a existência de imagens-link no menu.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 2.2

  Existe uma marcação hierarquizada de títulos e subtítulos na página <h1>...<h6>.
  – ver requisito 2.2 na lista 10 aspetos
  Existem cabeçalhos que não configuram secções, e devem ser removidos.

  

  Figura 1 - Um dos cabeçalhos da secção "Alertas e Avisos"

  Como é possível observar na figura, o cabeçalho de nível 2 “Interrupção de trânsito em Valongo - Festas da Cidade e Procissão de S. Mamede” constitui-se, atualmente, como uma subsecção da secção “Alertas e Avisos”.
  Este cabeçalho, bem como todos os demais da secção “Alertas e avisos” (que obedecem à mesma estrutura), encontram-se imediatamente uns a seguir aos outros, sem qualquer texto entre eles, pelo que não faz sentido que sejam considerados como início de novas secções. Para além disso, cada cabeçalho desta secção tem um link que o precede, e em que se verifica que o texto de cada link é igual ao texto de cada cabeçalho.

  Pelo exposto, e neste caso em particular, recomendamos a remoção completa dos elementos <h2> (inclusive o seu texto) dos itens da secção “Alertas e Avisos”.

  Existem outras secções na página inicial que têm a mesma estrutura da secção “Alertas e Avisos”, com os textos dos links igual aos textos dos cabeçalhos, e em que esses cabeçalhos e respetivos textos devem ser removidos, não só por não serem considerados secções, mas também para evitar a duplicação de informação.

  Referimo-nos aos cabeçalhos existentes nas seguintes secções:

  • Secção "EVENTOS EM DESTAQUE";
  • Secção "Acessos Rápidos";
  • Secção "Portais CMV", "Valongo, um território a descobrir!";
  • Secção que se estende desde "Saiba quanto custou" a "Mensagem do Presidente";
  • Secção que se estende desde "Publicações" a "Valongo em Agenda";
  • Secção que se estende desde "Apoios Comunitários" a "Inquéritos e Inscrições";
  • Secção que se estende desde "Loja Interativa de Turismo" a "Valongo Energy Hub";
  • Secção que se estende desde "Ferrovia" a "Bugios e Mourisqueiros".

  Diretamente relacionado com este ticket está o ticket “R 8.3 - 10 Aspetos - Existem links em cards e em listas de links estruturados de forma incorreta”, que recomenda a restruturação dos links destas mesmas secções de modo a torná-los visíveis.

  Para mais informações sobre como estruturar os cabeçalhos, partilhamos a seguir um ficheiro com notas de acessibilidade identificando os únicos locais que devem ser atribuídos cabeçalhos.

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem tabelas com vários tipos de informação no cabeçalho

  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

  Os controlos que permitem recuar e avançar um mês, presentes na tabela associada ao campo “Data de nascimento” do formulário INSCRIÇÃO - LAN HOUSE, devem ser colocados fora da tabela.

  

  A leitura da tabela por utilizadores de leitores de ecrã fica mais simples se apenas contiver a funcionalidade relativa aos dias do calendário, ficando os botões de recuo e avanço entre meses fora da tabela.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O elemento `` está a ser ocultado pelo CSS

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 3.2

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

  A tabela que estrutura o calendário associado ao campo “Data de nascimento” do formulário INSCRIÇÃO - LAN HOUSE tem o seu elemento <caption> escondido através da propriedade display: none do css.

  

  O uso da propriedade display: none pode gerar problemas de acessibilidade, pois além de esconder visualmente o elemento ela esconde também das tecnologias de apoio. Existem propriedades em CSS que permitem ocultar o conteúdo de forma visual, mantendo-o acessível às tecnologias de apoio.
  Recomendamos evitar o uso de display: none e como alternativa, sugerimos utilizar uma classe .hidden para esconder o conteúdo visualmente, mantendo-o acessível aos leitores de ecrã. Para mais informações, partilhamos o artigo CSS em Ação: Conteúdo Invisível apenas para Utilizadores de Leitor de Ecrã.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: As caixas de seleção não possuem legenda e etiquetas associadas ao campo

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.1

  Quando a legenda está corretamente associada ao grupo de opções, o leitor de ecrã consegue anunciar a legenda complementando a opção que está com foco:

  

  No entanto, a caixa de seleção do formulário de newsletter não apresenta o mesmo comportamento. Para além de ocultar o elemento input type="checkbox" das tecnologias de apoio — o que indica que não existe uma associação explícita entre a label e o input (uma vez que o input "não existe" pois se encontra com display: none) — está a ser utilizada uma lista ul li para agrupar as opções, sendo muito provável que esta esteja a ser usada apenas para fins de apresentação do layout:

  

  Recomendamos rever a caixa de seleção para garantir que a legenda está corretamente associada às respetivas opções. É necessário garantir a associação entre a label e o campo input, e verificar que as opções são acessíveis através do teclado, utilizando as teclas TAB e SHIFT+TAB.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: As mensagens de erro são exibidas uma de cada vez

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

  No formulário de newsletter é possível verificar que as mensagens de erro são exibidas uma por vez. Esta abordagem pode tornar mais difícil a compreensão do que necessita de ser corrigido, especialmente quando existem múltiplos campos com erros.

  

  Quando submetemos o formulário da newsletter sem preenchimento, a primeira mensagem que aparece é o preenchimento do reCAPTCHA

  

  Quando submetemos o formulário da newsletter sem preenchimento, a segunda mensagem que aparece é o preenchimento do email

  Isso também acontece no formulário de Sugestões / Exposições / Reclamações / Elogios, as mensagens são apresentadas uma de cada vez.

  

  Quando submetemos o formulário de feedback sem preenchimento, a primeira mensagem que aparece é o preenchimento do reCAPTCHA

  

  Quando submetemos o formulário de feedback sem preenchimento, a segunda mensagem que aparece é o preenchimento do Termo

  No formulário de Sugestões / Exposições / Reclamações / Elogios e de newsletter acontece também outro cenário, as mensagens de erro são apresentas no topo. No entanto, não ajuda o utilizador a localizar o respetivo campo com problema, pois a lista não permite localizar o campo. Isso faz com que o utilizador precise percorrer todos os campos para identificar o campo com problema de preenchimento.

  

  Recomendamos reverem os formulários para garantir que as mensagens de erro sejam apresentadas de forma consistente por todo o website. Elas devem ser apresentadas próximas ao campo e devem estar sempre visíveis para o utilizador, independentemente do campo estar ou não focado.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

  É possível identificar na galeria de imagens da página Brinquedos Tradicionais, imagens que não possuem um texto alternativo:

  

  Imagem não possui texto alternativo preenchido

  Recomendamos rever todo o website para garantir que todas as imagens possuem um texto alternativo. Imagens decorativas devem ter o texto alternativo atribuído como nulo alt="" e imagens que transmitem informação, como as que estão sendo apresentadas nas galerias, devem ter um texto alternativo que informe o seu significado.

• evidência: Existem imagens que estão com texto alternativo incorreto

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.1

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

  Na página inicial da CM Valongo é possível identificar imagens com texto alternativo no idioma inglês:

  

  Texto alternativo icondownload na imagem

  Para além disso, é possível identificar imagens com texto alternativo inapropriado e que deveriam ser decorativas:

  

  Recomendamos rever as imagens do website para garantir que texto alternativo transmita uma informação no mesmo idioma da página e as imagens tenham o texto alternativo que informe o utilizador ou que tenham seu texto alternativo preenchido como nulo (alt="").

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.2

  O website da Câmara Municipal de Valongo apresenta folhetos que são utilizados para divulgar os eventos. No entanto, em alguns casos, verifica-se que o texto que acompanha o folheto não contém todas as informações nele presentes. Por exemplo, na página do evento S. Silvestre de Ermesinde 2025 – Inscrições abertas, o texto não menciona que os participantes recebem um kit e outros materiais do evento, nem indica que existem duas fases de inscrição com datas definidas.

  

  Recomendamos rever todas as imagens do tipo "folhetos" para garantir que a informação da imagem também esteja apresentada no texto.

• evidência: O organograma possui descrição de díficil localização

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 5.2

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

  Na página Organograma, é apresentado um link que permite aceder a descrição em texto do Organograma. No entanto, o link esta após um bloco de texto e sua localização não está próxima da imagem:

  

  Para além disso, quando acedemos ao link, é apresentado um diretório da página documentação com 4 ficheiros PDF. Dificultando o acesso ao texto alternativo, pois será necessário o utilizador procurar a informação nos ficheiros:

  

  É fundamental disponibilizar a informação de forma clara e direta ao utilizador. Quando se tratar de um link, este deve estar associado ou próximo da imagem e fornecer a informação necessária de forma imediata, sem obrigar o utilizador a procurar em documentos PDF .

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem imagens-link com texto alternativo inapropriado

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 5.3

  Na homepage existem imagem-links com texto alternativo inapropriado, como por exemplo, as imagens-link da secção parceiros:

  

  Além de estar sendo utilizado números que não fazem parte da descrição do logotipo, o leitor de ecrã anuncia a imagem-link como: "iclei" + "tração" + "cento e cinquenta" + "tração" + "cem"

  No rodapé, as redes sociais possuem a descrição "Botão" junto ao texto alternativo. Isso faz com que o leitor de ecrã anuncie a rede social como um link (hiperligação) e informa no texto alternativo que é um botão:

  

  Leitor de ecrã informa que a rede social é um link e um botão ao mesmo tempo

  Na página Boletim Municipal existem imagens-link cujo texto alternativo está sendo utilizado para transmitir a data:

  

  _

  Recomendamos que o texto alternativo seja redigido sem o uso de caracteres especiais, como o sublinhado (_), números sem contexto ou a tipologia do elemento (por exemplo, “link” ou “botão”), uma vez que estes podem ser interpretados de forma incorreta pelos leitores de ecrã.
  Na homepage, no caso dos logótipos, o texto alternativo deve incluir a mesma informação que é apresentada visualmente no logótipo, como o nome por extenso (exemplo: ICLEI – Local Governments for Sustainability) e nas redes sociais devem remover o "botão" do texto alternativo.

  Na página Boletim Municipal recomendamos que essas imagens sejam decorativas, uma vez que o próprio link possui um texto que informa claramente o significado do link tanto visualmente como programaticamente.

• evidência: Existem imagens-link com texto alternativo em inglês

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 5.3

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

  Na página inicial, os controles de avançar e voltar do carrosel possuem texto alternativo em inglês:

  

  Recomendamos que o texto alternativo das imagens-link estejam no mesmo idioma do website.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: As legendas fechadas fornecidas pelos vídeos são automáticas

  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

  As legendas automáticas fornecidas pelo Youtube, utilizam recursos de reconhecimento de voz que tem melhorado ao longo do tempo, no entanto, ainda enfrentam limitações que podem prejudicar a acessibilidade, como por exemplo, ela pode não ser fiel ao conteúdo que está sendo apresentado.

  Na página Vídeos são apresentados vídeos que contém uma legenda aberta e uma fechada sendo esta gerada automaticamente pelo Youtube e apresentada na transcrição. No vídeo Documentário - Hóquei Um percurso sobre rodas a legenda fechada e transcrição não informa corretamente o conteúdo do vídeo:

  

  Legenda fechada informa "João em viveiro dos jogadores" sendo que o correto é "Valongo foi um viveiro de jogadores"

  Recomendamos reverem os vídeos para garantir que a legenda fechada e transcrição estejam igual a legenda aberta embutida nos vídeos.

• evidência: Não é possível ler a legenda do vídeo na página

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 7.2

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

  Na página a Mensagem do Presidente, encontram-se disponíveis legendas abertas e legendas fechadas. Contudo, nenhuma das opções é visível, uma vez que o vídeo está incorporado num formato demasiado reduzido. Esta limitação impede a visualização adequada das legendas e não permite expandir o vídeo diretamente na página do website forçando o utilizador a sair do website para assitir ao vídeo no Youtube:

  

  Opção modo de ecrã inteiro desativado na página do website

  Recomendamos que o vídeo seja apresentado num tamanho que possibilite a leitura nítida das legendas.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Texto de progresso de operação exibido inadequadamente para as tecnologias de apoio

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

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

  No formulário de SUGESTÕES / EXPOSIÇÕES / RECLAMAÇÕES / ELOGIOS o texto “A submeter o formulário. Por favor aguarde.” É apresentado às tecnologias de apoio, sem que esse formulário esteja efetivamente a ser submetido.

  

  Figura 1 - Ecrã de preenchimento de formulário, onde é apresentado um Texto de progresso de submissão às tecnologias de apoio

• evidência: Existência de cadeias numéricas inapropriadas nos links do menu principal

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

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

  Todos os elementos <a> do menu principal contêm um elemento <p> com uma string numérica, que está a ser escondida por css.

  

  Figura 1 - Exemplo de um link do menu principal que contém um elemento <p> com um texto numérico, que é ocultado por CSS

  Como se pode observar na figura, o link “Município” contém um elemento <p> com a string 7434, sendo que o conteúdo do elemento <p> está a ser escondido por CSS.

  Estamos perante uma situação de uso de elementos de html como auxiliares funcionais, mas que em nada enriquecem os conteúdos do site, para além de tornar o código mais difícil de compreender e de manter.

  Devemos realçar que, quem optar por visualizar a página com os estilos CSS desativados, vai-se deparar com estes números, sem perceber o real significado dos mesmos.

  Recomendamos a remoção de todos os elementos com cadeias de caracteres que não são parte do conteúdo efetivo do site, promovendo assim, não só um código mais limpo, e portanto mais compreensível e mais fácil de manter, como também a separação entre os conteúdos e os comportamentos.

• evidência: As subopções do menu aparecem antes das opções de primeiro nível

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.2

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

  É possível verificar que ao navegar com o leitor de ecrã nas opções do menu, as setas direcionais que indicam subopções são informadas antes da própria subopção. Isso faz com que não seja possível perceber que a subopção é de qual tema do menu:

  

  Subopção de Município é lido antes da opção município

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Uso inapropriado da tag "abbr"

  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

  A tag abbr está a ser utilizada nos formulários para indicar o significado do asterisco. No entanto, essa utilização é inapropriada. Para além de a estrutura estar oculta das tecnologias de apoio através do atributo aria-hidden, o atributo title está sendo substituído pela span:

  

  Recomendamos refazerem o texto que explique de forma clara o significado do asterisco, como por exemplo: "Os campos marcados com * são de preenchimento obrigatório". Nesse cenário não é necessário o uso da tag abbr:

  

  Exemplo

  Caso optem em manter a tag, é necessário garantir que a tag esteja visível e seu significado esteja informado através do title.

• evidência: Existem links usados como botões

  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

  No formulário SUBSCRIÇÃO DE NEWSLETTERS está a ser utilizado um link para submissão.

  

  Figura 1 - Link de submissão de formulário usado como botão

  Enquanto que os links servem para acesso a recursos, os botões servem para executar ações, sendo por isso mais correto que a ação de submissão do formulário seja realizada por um botão.
  Dessa forma, para além de ser usado o elemento adequado, é mantida a coerência com todos os outros formulários que já usam um botão para submeter a informação. Para além disso, esta mudança torna mais eficiente a navegação de utilizadores de leitores de ecrã, pois conseguem, apenas com uma tecla de navegação rápida, chegar a todos os botões de submissão de formulários, ao invés de terem de adivinhar o tipo de estrutura com que foi codificado cada controlo de submissão.
  Pelo exposto, recomendamos a utilização do elemento <input> nativo como controlo de submissão do formulário, e a utilização de css para estilizar esse botão de modo a ficar com o aspeto do link que atualmente existe.

• evidência: Existência de checkboxes personalizadas que não são focadas por teclado nem anunciadas por leitores de ecrã

  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

  As checkboxes que representam as newsletters passíveis de ser subscritas, no Formulário de Subscrição de Newsletters, são personalizadas com elementos <span> sem qualquer enriquecimento de acessibilidade. Tal facto impede, não só que essas checkboxes sejam focadas com o teclado (tab e shift+tab), mas também com que o tipo de controlo e estado sejam anunciados pelos leitores de ecrã.

  

  Figura 1 - Checkbox personalizada com um elemento span

  Devemos enfatizar que este problema é crítico para utilizadores exclusivos de teclado e para utilizadores de leitores de ecrã.

  Os primeiros não conseguem focar as checkboxes utilizando tab e shift+tab. Os segundos não conseguem saber qual o estado de cada checkbox, e mesmo que pressionem a tecla espaço em cada item, não percebem se houve alteração do estado.

  Recomendamos a substituição destas checkboxes por checkboxes nativas, pois são mais familiares aos utilizadores, permitem o anúncio pelos leitores de ecrã e têm menor propensão a erros comparativamente às checkboxes personalizadas.

  Caso pretendam continuar com as checkboxes personalizadas, a forma mais fácil é garantirem que os elementos <input type="checkbox"> correspondentes são escondidos apenas visualmente (e não para as tecnologias de apoio), para que as checkboxes possam ser focadas por teclado e anunciadas às tecnologias de apoio como se de controlos nativos se tratassem.

• evidência: existência de notícias incorretamente distribuídas por várias listas

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Na secção notícias da página inicial, as notícias estão distribuídas por várias listas.

  

  Figura 1 - Notícias distribuídas por três listas

  Como é possível observar na figura, as notícias estão distribuídas por três listas: a primeira lista com as cinco notícias do carrossel, a segunda com duas notícias e a terceira com quatro notícias.

  Semanticamente, o que faz sentido é a agregação de todas as notícias numa única lista, até porque
  não parece haver nenhuma característica que seja diferente nas notícias das várias listas.

  Pelo exposto, recomendamos a agregação de todas as notícias numa única lista. Quanto muito podem existir duas listas, caso seja pretendido que o carrossel não contenha todos os elementos. Nessa situação, uma lista conterá as notícias a constar do carrossel, e a outra lista conterá as restantes notícias.

• evidência: Texto dos links referenciado em vários locais

  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 texto das hiperligações do menu principal é referenciado em vários locais.

  

  Figura 1 - Composição de um link do menu principal

  Como se pode observar na figura, o texto de cada hiperligação do menu principal está repetido em três locais:

  • No atributo aria-label de cada elemento <a>;
  • No atributo title de cada elemento <a>;
  • Num elemento <span aria-hidden="true"> inserido dentro do <a>.
    Consideramos esta solução desnecessariamente complexa para o problema que procura resolver, além de tornar o código confuso e propenso a erros.
    As boas práticas recomendam que o texto de cada hiperligação exista apenas uma vez, diretamente no elemento <a>, de forma a estar visível no ecrã e acessível pelas tecnologias de apoio (sem o atributo aria-hidden).
    Neste cenário, os atributos aria-label e title tornam-se dispensáveis, simplificando o código e tornando-o mais fácil de manter.
    Recomendamos a revisão do conteúdo de todos os links de forma a que contenham o texto diretamente em cada elemento <a>, eliminando outros locais onde esse texto apareça.

• evidência: Existem links em cards e em listas de links estruturados de forma incorreta

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

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

  

  Figura 1 - link estruturado incorretamente num card

  Como se pode observar na figura, o card “Apoios Comunitários” é constituído por um link, uma imagem e um cabeçalho, em que o texto do link está oculto para todos os visitantes e o cabeçalho sobrepõe-se ao link servindo o seu texto como texto desse link. Estruturalmente, o link deve, só por si, desempenhar a sua função, sem elementos auxiliares.

  Este problema acontece na página inicial, nos seguintes cards:

  • Em todos os cards da secção que se estende desde " Apoios Comunitários" a " Inquéritos e Inscrições";
  • Em todos os cards da secção “EVENTOS EM DESTAQUE”;
  • Em todos os cards da secção “Valongo, um território a descobrir!”;
  • Em todos os cards da secção que se estende desde "Ferrovia" a "Bugios e Mourisqueiros".
    O mesmo problema verifica-se também nas seguintes listas de links:
  • Na lista de links da secção que se estende desde "Loja Interativa de Turismo" a "Valongo Energy Hub";
  • Na lista de links da secção “Portais CMV”
    Posto isto, recomendamos que, para cada link de cada card: e para cada link das listas de links:
  • seja eliminada a classe link-hidden do div que contém o texto de cada link;
  • Seja eliminado o atributo aria-label de cada elemento <a>, de forma a que o texto do link seja referenciado apenas pelo conteúdo da div encaixada nesse elemento <a>.

  Diretamente relacionado com este ticket está o ticket “R 2.2 - 10 Aspetos - Há cabeçalhos incorretamente atribuídos”, que recomenda a remoção de todos os cabeçalhos existentes nestas mesmas secções.

• evidência: O formulário não informa as etapas para os leitores de ecrã

  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 preenchimento do formulário da Ficha de Inscrição de Voluntários/as está dividido em etapas. Visualmente, é possível distinguir três fases: por preencher, em preenchimento e preenchido:

  

  Formulário da Ficha de Inscrição de Voluntários/as apresentando as fases visualmente de formas diferentes

  Essa distinção não é informada para os leitores de ecrã, isso faz com que não seja possível identificar o status de preenchimentos das etapas:

  

  Identificação foi preenchido e não está sendo informado para os leitores de ecrã

  

  Área de interesse está a preencher e não está sendo informado para os leitores de ecrã_

  

  Atividade de voluntariado em falta preencher não está sendo informado para os leitores de ecrã

  Recomendamos rever todos os formulários dividos por etapas para garantir que o status de preenchimento seja informado também para as tecnologias de apoio. Partilhamos um exemplo de formulário multi step da W3C que pode ajudar.

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Os itens da secção “Alertas e Avisos” funcionam segundo uma dinâmica de carrossel, que deve ser corretamente estruturado.

  

  Figura 1 - carrossel da secção "Alertas e Avisos"

  Verificamos que a passagem automática dos itens não pode ser pausada, nem colocando o foco sobre os mesmos, nem através de um botão que efetue essa pausa, o que dificulta a leitura dos itens.
  O carrossel das notícias também precisa de estar acessível.

  

  Figura 2 - Carrossel da secção "Notícias"

  Para além de não informar quantos itens fazem parte do carrossel, não permite pausar a passagem dos itens.
  Recomendamos que seja indicado visualmente o número de elementos de cada carrossel, e que a navegação seja exclusivamente controlada pelo utilizador, que pode ser através de dois botões para avançar e retrocedera e da inclusão de um botão que permita pausar a passagem dos itens.
  Para mais informações é possível consultar os artigos Carousel Structure e Carousel (Slide Show or Image Rotator) Pattern do W3C.

• evidência: Existem controlos incorretamente enriquecidos com acessibilidade

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

  O campo “Tipo de Formulário” do formulário SUGESTÕES / EXPOSIÇÕES / RECLAMAÇÕES / ELOGIOS foi enriquecido com atributos de acessibilidade de forma incompleta e incorreta.

  

  _Figura 1 - Combobox personalizada com um um elemento <input> enriquecido com acessibilidade de forma incorreta

  Como é possível observar na figura, o campo input foi dotado com o atributo role=”combobox”, o que faz com que que a sua semântica seja a de uma combobox, sendo esse o tipo de controlo que é anunciado pelas tecnologias de apoio.

  No entanto, a navegação pelas opções da suposta combobox não funciona como numa combobox nativa, e isso constata-se claramente quando navegamos com as setas e os elementos não são automaticamente anunciados pelos leitores de ecrã.
  Assim, os utilizadores destas tecnologias têm de efetuar um esforço tremendo para entenderem o mapa mental de navegação subjacente a este controlo, e nem sempre isso é possível. Por exemplo, o leitor de ecrã NVDA só anuncia o elemento selecionado após ser pressionada a tecla tab, mas não em todas as situações.
  Associado à combobox está um botão “×” que, ao ser clicado, inibe a combobox de transmitir ao leitor de ecrã qual o item que ficou selecionado.

  Recomendamos a reformulação de todas as comboboxes deste género, de modo a torná-las controlos nativos, e com isso mais simples de manter e navegar. Caso as comboboxes tenham especificidades que não sejam atendidas pelos elementos <select> nativos, recomendamos a sua adaptação de acordo com um dos exemplos de boas práticas da W3C, onde podem consultar um exemplo de combobox acessível e hiperligações que remetem para outros tipos de comboboxes igualmente acessíveis.

• evidência: Existem elementos com a semântica incorreta

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

  Os elementos da página devem estar identificados com a semântica de HTML certa para que sejam interpretados corretamente pelas tecnologias de apoio.

  Na página Vídeos, está sendo utilizado modais para apresentar os vídeos da página. Os seus respetivos controles de avançar e fechar estão sendo construídos por div genéricas o que impossibilita a sua seleção pelos teclado e leitores de ecrã. Para além disso, os ícones estão inseridos via CSS o que fazem sumir quando desligamos o CSS:

  

  Controles de avançar e voltar da modal construídos por div e ícones inseridos via CSS

  No formulário Biblioteca Humana - Ficha de avaliação é possível identificar que a funcionalidade de remover a opção selecionada está sendo construída como uma span ao invés de ser um elemento interativo do tipo button. Isso faz com que também não seja acessível pelo teclado:

  

  Recomendamos utilizarem elementos nativos do HTML, como links a e botões button para garantir que esses elementos interativos sejam acessíveis por outras formas além do rato.

• evidência: Existem conteúdos que não estão estruturados como lista de forma apropriada

  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 breadcrumbs das páginas interiores estão identificados como uma lista não ordenada ul li ao invés de ser uma lista ordenada ol li:

  

  A ordem da informação apresentada no breadcrumb é importante. Por esse motivo, recomendamos que seja implementado como uma lista ordenada (ol e li). Para além disso, sugerimos que o breadcrumb seja definido como um elemento de navegação (nav) com a devida nomenclatura. Tal pode ser feito através da utilização do atributo aria-label="Você está aqui".

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O foco não é direcionado para dentro da modal

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

  Quando uma modal é aberta, o foco do teclado e leitor de ecrã deve ser automaticamente direcionado para dentro dela. Isto garante que os utilizadores que navegam com o teclado, incluindo aqueles que recorrem a tecnologias de apoio, possam interagir facilmente com o conteúdo apresentado e percebam que uma nova interação está disponível.

  Na página de Vídeos, para cada vídeo abre uma modal e o foco do leitor de ecrã não é automaticamente direcionado para dentro do seu conteúdo:

  

  Foco do leitor de ecrã encontra-se abaixo da modal em outro vídeo

  Recomendamos ajustar o foco para que, ao abrir a modal, o cursor seja automaticamente direcionado para o campo de pesquisa.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.3

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

  Na página de Vídeos, embora as modais apresentem um botão de fechar, ele não está acessível com o teclado e leitor de ecrã:

  

  Recomendamos rever o botão de "Fechar” das modais para garantir que estejam corretamente construídos e acessíveis pelo teclado e leitor de ecrã.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 9.4

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

  Na página de Vídeos é possível identificar vídeos que são apresentados dentro de modais. Pelo navegador Safari está funcionando corretamente. No entanto, quando fechamos a modal de vídeo no Chrome utilizando a tecla ESC o mesmo retorna para a funcionalidade de ouvir o conteúdo:

  

  Foco no card para abrir a modal

  

  Ao fechar modal o foco é movido para a função de ouvir conteúdo

  Recomendamos rever todas as modais apresentadas no website para garantir que ao fechar a modal, o foco esteja no botão acionador da modal independente de qual navegador o utilizador esteja a usar.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: A informação tem um tamanho de letra inferior 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

  Na página Eleitos Assembleia Municipal existem conteúdos com tamanho de fonte de 15.2px e sendo parte da principal informação da página, devem ter no mínimo tamanho de fonte de 16px:

  

  Isso está a acontecer em outros locais do website, como por exemplo, nas páginas de endereços, em Museu da Lousa:

  

  Embora a maioria dos blocos de texto apresente um tamanho conforme o recomendado, identificámos alguns elementos em que o tamanho do texto está abaixo do ideal. Sendo estes elementos interativos e responsáveis por transmitir informação relevante ao utilizador, recomendamos que o tamanho mínimo do texto seja de 16px.

  Por exemplo, as opções de segundo nível do menu apresentam um tamanho de 14px, o que é inferior ao recomendado:

  

  No formulário PROJETO TOP, as etiquetas e as mensagens de erros são consideradas informações primárias e possuem tamanho de texto de 13px, o que está abaixo do recomendado:

  

  O mesmo acontece em outros locais do website, como por exemplo, as opções da caixa de seleção do formulário da Newsletter:

  

  Nos formulários do website, como por exemplo, PROJETO TOP o asterisco (*) está informando quais campos são obrigatórios, tal informação é uma informação importante e considerada como primária. Por esse motivo, seu tamanho deve ser de, no mínimo 16px:

  

  Campos obrigatórios indicados pelo asterisco (*) estão com tamanho abaixo do recomendado

  Recomendamos rever o menu principal e todos os formulários do website para garantir que as opções do menu, as devidas etiquetas e mensagens de erro dos formulários tenham tamanho de no mínimo 16 píxeis.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: A informação secundária tem um tamanho de letra inferior a 13px

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

  O tamanho de letra dos links do rodapé é de 12.8px, pelo que deverá ser corrigido para um tamanho igual ou superior a 10pt (13px):

  

  Links Mapa do Site, Ficha Técnica, Contactos da Autarquia e Serviços, Feed RSS, Acessibilidade, Glossário de Termos Complexos, Conformidade, Transparência e Dados Abertos, Avisos Legais com tamanho abaixo do recomendado

  Recomendamos rever todo o website para garantir que os links e informações secundárias tenham tamanho de fonte de no mínimo, 13px.

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

Lista de evidências recolhidas:

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

  etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: R 3.2

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

  Para ser mais claro onde se encontra o menu quando está colapsado, no caso de breakpoints de tablet e mobile, orientamos que o ícone que representa o menu seja acompanhado de um texto descritivo (ex: “Menu”).

  

  Recomendamos adicionar o texto descritivo “Menu” ao ícone. Um bom exemplo a considerar é o menu do selo:

  

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O índice apresentado em algumas páginas não direciona o utilizador para a secção de forma apropriada

  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

  Na página Candidaturas a Apoios Comunitários é apresentado um índice com opções que não refletem o mesmo nome da secção. Por exemplo, ao clicar em "Plano de Recuperação e Resiliência - Recuperar Portugal" é direcionado para a secção "Programa de Apoio ao Acesso à Habitação":

  

  Ao clicar num link e ser direcionado para uma secção cujo título difere do nome apresentado no link, podem surgir dúvidas quanto à navegação. Por esse motivo, recomendamos a revisão do índice atualmente utilizado no website, de forma a garantir que a designação de cada link corresponda exatamente ao título da secção para a qual encaminha o utilizador

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

Lista de evidências recolhidas:

• evidência: O conteúdo do site não se adapta às diferentes resoluções de ecrãs

  etiqueta: chk conteúdoetiqueta: melhoriaetiqueta: R 4.2

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

  O layout do site deve ter comportamento responsive, ou seja, deve-se adaptar às diferentes resoluções de ecrãs, de forma a garantir que a navegação seja fluída e não haja conteúdo cortado.

  É possível observar que o layout do site não se adapta as resoluções menores quando também é aplicado o zoom:

  

  Página inicial com scroll horizontal, botão selecionar idioma aparece "cortado", o menu está fixo sobrepondo a outros conteúdos

  Recomendamos o layout do website tenha um comportamento responsive e adapta-se às diferentes resoluções de ecrã, sem necessidade de fazer varrimento horizontal.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Há elementos interativos que não aparentam ser clicáveis

  etiqueta: chk conteúdoetiqueta: NOKetiqueta: R 5.4

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

  A secção de eventos apresentada na página inicial do website contém cartões que não se encontram devidamente alinhados, formando uma espécie de “escada”. Para além de o limite de cada cartão não estar claramente definido, esta disposição irregular dificulta a perceção da área clicável ainda mais quando utilizamos recursos de ampliação no ecrã:

  

  Recomendamos que seja revisto o estilo dos elementos interativos para que seja mais percetível que são clicáveis. Uma possível solução seria deixar mais nítido a área do cartão.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: chk transaçãoetiqueta: NOKetiqueta: 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

  Em formulários longos, com mais de 2 ecrãs de altura, deve-se garantir que a informação é pedida ao utilizador de forma faseada, dividindo os passos em várias páginas ou secções. Essa abordagem reduz a carga cognitiva permitindo que pessoas com deficiência cognitivas preencham de forma mais assertiva.

  O formulário de FUNCIONAMENTO DO CONSELHO MUNICIPAL DE EDUCAÇÃO – 2021/2025 quando navegamos na resolução desktop (1024px) é possível perceber que o seu tamanho é maior que 2 ecrãs.

  Já no formulário de Candidatura a Bolsa de Estudo da Universidade Lusófona do Porto - Ano letivo 2025/2026 acontece um cenário diferente, o tamanho dos campos é dinâmico, ou seja, ele muda de acordo com o número preenchido no campo "N.º de elementos que compõem o agregado familiar, incluindo o/a candidato". Caso o utilizador insira um número maior que 3, o formulário passa a ser muito longo para o ecrã.

  Recomendamos reverem a estrutura dos formulários mais longos, de forma a segmentar as etapas de preenchimento com um formulário baseado em etapas, como está feito também em alguns formulários do website.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: O tamanho do campo nome e email 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

  A largura do próprio campo deve refletir o tamanho previsível dos dados a preencher, principalmente em campos de escrita livre em que o utilizador deve inserir os seus próprios dados.

  No caso do formulário de Subscrição, a largura dos campos nome e email não refletem o tamanho previsível dos dados:

  

  Campos nome e email demasiados grandes para preenchimento

  Isso acontece em outros formulários, como por exemplo, no formulário PROJETO TOP, a largura dos campos nome, email e contacto telefonico não refletem o tamanho previsível dos dados:

  

  Campos nome, email e contacto telefonico demasiados grandes para preenchimento

  Recomenda-se a revisão dos campos dos formulários, garantindo que a largura dos campos está adequada ao tipo de informação a inserir, como é feito em outros formulários no website:

  

  Campos nome e email com tamanho previsível de preenchimento do formulário Sugestões / Exposições / Reclamações / Elogios

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

  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

  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.

  No campo contacto telefónico do formulário PROJETO TOP, verificou-se que é possível inserir letras e caracteres especiais, quando o campo deveria apenas aceitar números:

  

  Recomendamos rever de modo geral todos os formulários do website para garantir que exista um limite do tipo de caracteres que é possível inserir, consoante o tipo de campo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Existem campos do formulário sem legenda

  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

  A legenda deve permanecer sempre visível, mesmo quando o utilizador interage com o campo. Desta forma, não precisa de se lembrar da informação, reduzindo assim o esforço cognitivo.

  Manter a label visível no ecrã, amplia-se a área de clique, o que pode beneficiar pessoas com dificuldades motoras ao selecionar um campo específico.

  No formulário de Newsletter é possível observar que a legenda do campo nome e email desaparecem quando o utilizador interage com o campo para preencher os dados pedidos.

  

  Campos nome e email apenas com placeholder visível

  Para além disso, nas caixas de seleção do formulário Newsletter não existe uma legenda atribuída a esse grupo:

  

  Caixas de seleção não possuem legenda

  Recomendamos que nos campos input sua a label esteja sempre visível, de forma a garantir que, durante o preenchimento do campo, o respetivo nome não se perca. As caixas de seleção devem ter uma legenda para informar o tipo de seleção que está sendo feita, para isso, recomendamos que seja estruturada utilizando os elementos fieldset, legend e input type="checkbox", pois o campo input type="checkbox" está estruturado no HTML, mas está sendo escondido das tecnologias de apoio, as suas respetivas caixas de seleção estão sendo inseridas via CSS.

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

Lista de evidências recolhidas:

• evidência: Não é informado aos leitores de ecrã sobre o sucesso/erro do envio de informações automaticamente

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

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

  Idealmente as mensagens de status devem ser informadas automaticamente para as tecnologias de apoio assim que tiver mudanças na página. As mensagens podem ser determinadas programaticamente de modo que possam ser apresentadas para o utilizador.

  Quando submetemos o formulário de Newsletter é apresentado uma mensagem de confirmação. No entanto, o foco do leitor de ecrã retorna para o início da página e a mensagem de confirmação não é informada automaticamente.

  

  Ao submeter o formulário de newsletter o foco do leitor de ecrã retorna para o logótipo do website e a mensagem de confirmação não é informada para o leitor de ecrã

  Recomendamos rever os formulários para garantir que as mensagens de sucesso/confirmação/problema sejam automaticamente informadas para o leitor de ecrã.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: Não existem formulários que permitem 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

  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: OK (no entanto contém 1 melhoria que se recomenda efetuar)

Lista de evidências recolhidas:

• evidência: É necessário existir três locais de apresentação das mensagens de erro?

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

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

  No formulário PROJETO TOP é possível identificar três formas distintas de apresentação das mensagens de erro. Apesar de cada abordagem ser válida por si só, o problema reside na utilização simultânea desses três métodos, o que provoca uma sobrecarga de informação e pode dificultar a experiência do utilizador durante o preenchimento do formulário.

  

  Formulário apresenta 3 abordagens diferentes para apresentar as mensagens de erro do formulário

  Recomendamos reverem todos os formulários do website para garantir que utilizem apenas 1 abordagem e que a apresentação das mensagens de erro seja igual para todas. Como sugestão, podem optar por apresentar a mensagem de erro próxima ao seu respetivo campo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: 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

  Os campos dos formulários devem devolver mensagens de erros explícitas sobre como resolver o problema identificado em cada campo.

  No formulário do PROJETO TOP, a mensagem de erro do campo email não explica devidamente qual é o formato a ser inserido, revelando apenas "O '5. E-mail' indicado não é válido". O campo de contacto telefónico também não explica o tipo de informação a ser inserida, revelando "O campo '6. Contacto telefónico' é obrigatório":

  

  Campo email e telefone possuem mensagens de erro que não ajudam durante o preenchimento

  Percebemos que, ao insistir em submeter o formulário com o mesmo erro nos dois campos, é apresentado uma segunda mensagem de erro por parte do navegador que explica melhor o que precisa ser preenchido:

  

  Campo email com segunda mensagem de erro explicando como preencher corretamente

  

  Campo contacto telefonico com segunda mensagem de erro explicando como preencher corretamente

  Recomendamos rever todos os formulários do website para garantir que a mensagem de erro apresentada pela primeira vez já explique para o utilizador como preencher o campo corretamente.

  Verificámos também que são utilizadas duas abordagens diferentes para apresentar os erros nos campos nos formulários. Esta duplicação de mensagens gera redundância e pode dificultar o preenchimento por parte dos utilizadores. Recomendamos que cada campo apresente apenas uma mensagem de erro clara e objetiva, garantindo que a mesma ajude utilizador na correção do preenchimento.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: Outras violações - Existem calendários não acessíveis por teclado

  etiqueta: outras violações

  O calendário estruturado através de uma tabela, associada ao campo “Data de nascimento” do formulário INSCRIÇÃO - LAN HOUSE, não é acessível através do teclado.

  

  Apesar de ser possível escrever a data na caixa de texto, não é possível selecioná-la utilizando o calendário, via teclado. Em particular, não é possível focar o calendário utilizando a tecla tab, nem percorrê-lo utilizando as setas direcionais.
  Eis algumas alternativas já implementadas e testadas que podem ser usadas para restruturar o componente, que podem envolver a substituição da tabela:

  • Recurso Date Picker Dialog Example da W3C, em que é usado um botão que, ao ser premido, foca o calendário;
  • Recurso DatePicker do carbon design system, que coloca o calendário na lista de elementos focáveis com o tab.
    Em ambos os exemplos é possível percorrer o calendário com as setas direcionais.

• evidência: Outras violações - A data está sendo lida de forma inapropriada pelo leitor de ecrã

  etiqueta: melhoriaetiqueta: outras violações

  A data de atualização que está a ser apresentada nas páginas do website está sendo escrita como texto no formato ano/mês/dia. Isso faz com que o leitor de ecrã anuncie a data de forma inapropriada:

  

  Voice Over informa a data como: Dois mil e vinte e cinco + barra + zero nove + barra + vinte e seis

  Para garantir a data seja corretamente interpretada pelos leitores de ecrã, recomendamos sempre que possível escreverem a data no seguinte formato: 26 de Setembro de 2025.

• evidência: A etiqueta está a ser lida duas vezes pelo leitor de ecrã

  etiqueta: outras violações

  No formulário de Sugestões, reclamações e elogios, as etiquetas dos campos estão a ser lidas de forma duplicada pelo leitor de ecrã. Esta situação ocorre em todos os formulários do website.

  

  Etiqueta "Nome (obrigatório) anunciada duas vezes pelo leitor de ecrã

  Todo o campo deve estar associado programaticamente à sua etiqueta. No entanto, o que acontece nos formulários da CM Valongo é o uso de várias técnicas para o mesmo objetivo, o que faz com que o leitor de ecrã leia a etiqueta de forma repetida. Nesse caso, recomendamos associar a etiqueta ao campo através dos atributos for e id (que já está a ser utilizado) e remover os atributos aria-labelledby e aria-describedby.

• evidência: Outras violações - Existência de nomes acessíveis de botões noutro idioma

  etiqueta: outras violações

  O nome acessível dos botões do carrossel da secção de notícias da página inicial está em inglês.

  

  Figura 1 - Botões do carrossel presente na secção notícias da página inicial

  Recomendamos a alteração dos nomes acessíveis de todos os controlos para o idioma do site.

• evidência: Outras violações - Existem ícones não coincidentes com a função dos respetivos links a que estão associados

  etiqueta: outras violações

  O ícone de “Valongo em Agenda” é um link de transferência, mas o link que lhe está associado abre uma nova página.

  

  6Figura 1 - Ícone correspondente à função "Valongo em Agenda"

  Recomendamos a substituição do ícone atual por um outro que se adeque à função que o link que lhe está associado desempenha.

• evidência: Outras violações - Existência de notícias repetidas

  etiqueta: outras violações

  Na secção notícias da página inicial Existem notícias que se repetem nas várias listas, o que dificulta a leitura da secção, principalmente por parte dos utilizadores de tecnologias de apoio, no que toca ao discernimento de quais os títulos das notícias que são diferentes dos que já foram lidos.
  Recomendamos que sejam eliminados os títulos das notícias repetidas.

• evidência: Outras violações - O link de saltar para conteúdo principal não está acessível

  etiqueta: outras violações

  O link de saltar conteúdo é uma funcionalidade que permite ao utilizador aceder diretamente ao conteúdo principal da página, evitando percorrer elementos repetitivos da parte superior (menu, ligações, pesquisa, etc.).

  Para que o link de saltar conteúdo seja acessível, é necessário garantir a sua correta implementação, a saber:

  1. Quando utilizamos a tecla TAB com o teclado ou leitor de ecrã, o primeiro item a receber foco é o link de saltar conteúdo. O link não precisa ser visível na página, no entanto, devem garantir que quando recebe o foco ele se torne visível. Para isso, recomendamos consultarem o artigo CSS em ação: Links "saltar navegação".

  

  Link de saltar conteúdo principal não é visível e acessível pelo teclado ou leitor de ecrã

  2. Ele deve ser construído estruturalmente apenas como um link. Recomendamos evitar o uso de demasiadas funções na estrutura. Para isso, é necessário remover o h1 dentro do link.

  

  Link sendo estruturado com h1 de forma inapropriada

  3. Deve ter um nome acessível que explique o seu conteúdo. Para isso, é necessário remover o aria-label="Título" e manter apenas o texto do link como nome acessível.

  

  Link de saltar conteúdo com o aria-label utilizado de forma inapropriada

  4. É necessário garantir que quando o link estiver visível, ele esteja acima do contraste recomendado (4,5:1 para texto com o fundo e 3:1 para o corpo do elemento com a cor de fundo).

• evidência: Outras violações - Existem campos opcionais que não são identificados como tal

  etiqueta: outras violações

  No formulário de Questionário de Avaliação da Satisfação dos Munícipes é possível identificar campos obrigatórios sendo informados programaticamente e com visualmente pelo asterísco (*). E no mesmo formulário, é possível identificar campos opcionais pela etiqueta e outros campos opcionais que não possuem a mesma informação na etiqueta:

  

  Campos opcionais descritos pela etiqueta e campos opcionais sem essa descrição na etiqueta

  Recomendamos rever todos os formulários para garantir que as informações sejam passadas de forma padronizada em todos os campos, como por exemplo, se o campo é opcional todos os campos devem conter (opcional) na etiqueta ou vice-versa.