Relatório Avaliação de Candidatura
Câmara Municipal de Pombal (sítio Web institucional)

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

Lista de evidências recolhidas:

• evidência: issue #93 Não é possível identificar qual opção está com foco pelo teclado

  etiqueta: chk 10 webetiqueta: R 1.2etiqueta: melhoria

  É 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

  Evidencias
  Ao navegar pelas opções do menu utilizando o teclado, através das teclas TAB e SHIFT + TAB, não é perceptível a posição actual do utilizador nos botões de subopções do menu.

  

  Não é visível que o foco está no botão de abrir a subopção de município

  URLs a verificar

  • https://www.cm-pombal.pt/ - menu principal

  Recomendações

  • Definir um estilo visível para o contorno dos elementos interativos, utiizando à propriedade outline em CSS.
  • Outra alternativa, é manter o comportamento nativo dos navegadores, procedendo à remoção dos atributos de contorno actualmente definidos em CSS.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #105 Existem títulos e subtítulos incorretos e outros em falta

  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

  Evidencias:

  Nota: as páginas aqui indicadas são exemplos, devem ser corrigidas todas as situações iguais noutras páginas do site.

  M. Pombal (NOK)

  • Evidência checklist: homepage, não existe título de nível 1 (desconhecemos em que site estamos), nok
  • Em https://www.cm-pombal.pt/municipio/camara-municipal , o título de nível 1 encontra-se no rodapé, nok
  • As páginas deste site, começam com títulos nível 2

  Recomendações:

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #87 Marcação das células que constituem os cabeçalhos da tabela com o elemento <th>

  etiqueta: R 3.1etiqueta: chk 10 web

  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

  Melhoria
  A tabela presente na página Regulamento Municipal de Alienação de Lotes e Ocupação da Zona Industrial da Guia contém os seus cabeçalhos no elemento tbody.

  

  Tabela com cabeçalhos no tbody

  O mesmo acontece na tabela presente na página Política de Cookies.
  Recomendamos criar um elemento thead e mover a linha com os cabeçalhos para lá.

  NOK
  A tabela presente na página Política de Cookies não tem os cabeçalhos em elementos th.

  

  Tabela sem elementos th nas células de cabeçalhos

  Recomendamos a substituição dos td das células de cabeçalhos por elementos th.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #83 Marcação da legenda da tabela com o elemento <caption>

  etiqueta: R 3.2etiqueta: chk 10 web

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

  A tabela presente na página Política de Cookies não tem um título.

  

  Tabela sem caption

  Recomendamos introduzir um elemento <caption> na tabela com um título adequado.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #124 Existem etiquetas em formulários PDF não discerníveis semanticamente

  etiqueta: R 4.1etiqueta: chk 10 webetiqueta: NOK

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

  Evidencias:
  O formulário pdf presente na página Requerimento de Benefícios Fiscais não tem etiquetas discerníveis pelas tecnologias de apoio:

  

  Formulários como este excluem cidadãos do seu preenchimento

  URLs a verificar:
  https://www.cm-pombal.pt/viver/reabilitacao-urbana/requerimento-de-beneficios-fiscais?WAI-FID=3aad4d00-6fd1-11f1-aeab-b10dbc366a04
  Recomendações:
  Uma sugestão é ser disponibilizar os formulários diretamente em páginas web, garantindo melhor compatibilidade com leitores de ecrã e restantes requisitos de acessibilidade.

• evidência: issue #107 Existem etiquetas invisíveis no ecrã

  etiqueta: R 4.1etiqueta: chk 10 webetiqueta: NOK

  O formulário De pesquisa geral do site (em todas as páginas) tem a sua etiqueta invisível no ecrã.

  

  label com classe sr-only

  Apesar de o texto da etiqueta estar visível para as tecnologias de apoio, não é possível fazer clique no texto da mesma para focar o respetivo campo, já que o elemento <label> está oculto.

  Problema idêntico acontece na secção Resultados da pesquisa:

  

  label com a classe hidden

  URLs a verificar:

  • https://www.cm-pombal.pt/resultados_pesquisa?search_terms=Munic%C3%ADpio
  • Todas as páginas para o formulário de pesquisa geral

  Recomendações:
  Recomendamos que as etiquetas de todos os formulários e os seus textos estejam visíveis no ecrã.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #125 Atributos required incorretamente aplicados em etiquetas

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 4.2

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

  Evidencias:
  No formulário Newsletters existem atributos required = “required” nas etiquetas:

  

  A sintaxe required = “required” não existe. Ou bem que é utilizada a forma longa, required = “true”, ou bem que é utilizada a forma curta, required.
  Nas etiquetas, o atributo required não tem qualquer efeito, dificultando até a legibilidade e a manutenção do código.
  URLs a verificar:
  https://www.cm-pombal.pt/newsletters-65
  Recomendações:
  Recomendamos que os atributos required apenas sejam aplicados aos campos e não às etiquetas.
  Para além disso, não devem ser utilizadas formas sintáticas incorretas deste atributo, pois a forma como diversas tecnologias de apoio ou browsers as vão interpretar é indeterminada.

• evidência: issue #106 Não é possível identificar campos de preenchimento obrigatório nos formulários em PDF

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 4.2

  Evidências:
  Verificámos que, no formulário pdf presente na página Requerimento de Benefícios Fiscais, os campos de preenchimento obrigatório não se encontram identificados de forma clara.
  A obrigatoriedade dos campos não é comunicada visualmente de forma evidente nem transmitida corretamente às tecnologias de apoio, como leitores de ecrã.

  Sempre que possível, recomenda-se a disponibilização destes formulários diretamente em páginas web, em vez de exclusivamente em formato PDF. Em formulários web, os campos obrigatórios devem ser corretamente identificados através de atributos como required ou aria-required="true", garantindo a sua perceção por tecnologias de apoio.

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

  

  Formulário “Requerimento de Benefícios Fiscais” sem identificação clara dos campos de preenchimento obrigatório, quer visualmente quer através de tecnologias de apoio

  URLs a verificar:
  https://www.cm-pombal.pt/viver/reabilitacao-urbana/requerimento-de-beneficios-fiscais?WAI-FID=3aad4d00-6fd1-11f1-aeab-b10dbc366a04

  Recomendações:
  Recomenda-se que os campos obrigatórios dos formulários PDF sejam identificados de forma clara e consistente, tanto visualmente como para tecnologias de apoio, permitindo a sua correta perceção por todos os utilizadores.

  Uma sugestão é ser disponibilizar os formulários diretamente em páginas web, garantindo melhor compatibilidade com leitores de ecrã e restantes requisitos de acessibilidade.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #66 Há 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

  Evidências:

  • 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.
  • Há imagens informativas que não possuem um texto alternativo.
  • Caso seja necessário incluir uma descrição longa da imagem, esta deve ser colocada próxima da imagem ou numa página à parte que esteja hiperligada à imagem em questão.

  As evidências (1 e 2) apresentam imagens com textos alternativos inadequados em relação ao seu conteúdo. Por exemplo, na evidência (1), a página “Plano de Ação de Mobilidade Urbana Sustentável” contém uma imagem com o texto alternativo alt="imagem", que não descreve nem contextualiza o conteúdo para utilizadores de leitores de ecrã.

  

  URLs a verificar

  • (1) NOK. https://www.cm-pombal.pt/informar/mobilidade-e-acessibilidade/plano-de-acao-de-mobilidade-urbana-sustentavel
  • (2) NOK. https://www.cm-pombal.pt/visitar/o-que-visitar/galeria

  Recomendação
  Revisar todas as imagens e seus textos alternativos para que reflitam corretamente o propósito e o contexto das imagens, garantindo conformidade com as diretrizes de acessibilidade.

• evidência: issue #65 Imagens decorativas atribuídas corretamente nas notícias

  etiqueta: chk 10 webetiqueta: R 5.1

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

  Evidências:

  • No caso das imagens dos cards que sejam acompanhadas de texto, devem ser consideradas como decorativas e não funcionais. Sendo assim, o seu texto alternativo deve ser nulo ou devem ser adicionadas como background-image em CSS.

  Na página Notícias, existem cartões compostos por imagem e texto, sendo que as imagens incluem texto alternativo semelhante ao título da notícia. Ao navegar por essas componentes dos cartões com leitor de ecrã, a informação do título é repetida, uma vez que está presente no link do cartão, no próprio título e no texto alternativo da imagem. Esta implementação gera ruído devido à duplicação de informação, afetando negativamente a experiência de utilizadores que recorrem ao leitor de ecrã NVDA.

  URLs a verificar

  • (1) CM Pombal https://www.cm-pombal.pt/municipio/comunicacao/noticias?news_list_106_page=2

  Recomendações de melhoria

  • Para evitar que o leitor de ecrã repita várias vezes a mesma informação, as imagens dos cards devem ser consideradas como decorativas e é necessário incluir o texto alternativo como nulo da seguinte forma: (alt=””). Outra forma é adicionar as imagens via CSS.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #53 Organogramas com descrição longa

  etiqueta: chk 10 webetiqueta: R 5.2

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

  Evidências:

  O critério está a cumprir. A correção do Organograma foi feita, com histórico da correção disponível no Repositório 12. Atualmente, o "Organograma" possui seu conteúdo acessível com uma descrição longa associada na página Organograma. (Figura 01)

  

  Figura 1 - Organograma da Câmara Municipal de Pombal possui descrição longa associada

• evidência: issue #52 Representações gráficas acompanhadas de uma descrição longa

  etiqueta: chk 10 webetiqueta: R 5.2

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

  Evidências:

  • 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.

  A evidência (1) mostra que, na página “Mapas Turísticos”, são apresentadas duas imagens referentes ao Mapa da Cidade de Pombal e ao Mapa do Concelho de Pombal. No entanto, nenhuma destas imagens disponibiliza uma descrição longa que traduza, em formato textual, a informação geográfica, os pontos de interesse assinalados ou a estrutura dos percursos representados nos mapas. O texto alternativo existente é insuficiente e não comunica o conteúdo nem o propósito informativo dos mapas. (Figura 1)

  

  Figura 1 - Mapas interativos sem descrição longa

  Como resultado, utilizadores de leitores de ecrã não conseguem aceder aos detalhes necessários para compreender a localização espacial, vias principais, pontos turísticos e restantes elementos relevantes.

  URLs a verificar

  • (1) NOK https://www.cm-pombal.pt/visitar/posto-informacao-turistica/mapas-turisticos

  Recomendações:
  Fornecer alternativas textuais completas e programaticamente determináveis para todos os elementos gráficos do mapa e atribuir um nome acessível ao iframe (por exemplo, através de title), de modo a comunicar claramente a sua função e localização na página às tecnologias de apoio.

  • Adicionar um texto alternativo significativo e disponibilizar uma descrição longa que apresente os elementos estruturais do mapa, garantindo assim uma perceção equitativa da informação.

etiqueta: NOK

Lista de evidências recolhidas:

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

  Evidências:

  • As hiperligações compostas apenas por uma imagem obrigam que esta tenha um equivalente alternativo em texto que represente fielmente o destino da hiperligação.

  Na evidência (1) foi identificada a utilização do atributo title nas imagens-links presentes no rodapé “Livro de reclamações” e “Acessibilidade do site”. Este atributo deve ser removido, uma vez que não é anunciado de forma consistente por todos leitores de ecrã. Além disso, os ícones destes links são aplicados via CSS como imagem de fundo (background-image), o que impede a sua exposição na árvore de acessibilidade e impossibilita a definição de texto alternativo adequado.

  

  URLs a verificar

  • (1) NOK. https://www.cm-pombal.pt/

  Recomendação
  Recomendamos a revisão das imagens-link e atualização dos seus textos alternativos, assegurando que descrevem de forma clara e objetiva o conteúdo e o destino da hiperligação.

  • Substituir os ícones aplicados via CSS, por SVG inline dentro do HTML, permitindo controlo total sobre acessibilidade. Como os ícones representam ação para o redirecionamento a outras páginas, recomendamos incluir os textos alternativos:

  <a href="..." aria-label="Livro de Reclamações, abre em link externo”></a>
<a href="..." aria-label="Acessibilidade do site, abre em nova janela”></a>

  • É necessário rever as boas práticas de acessibilidade em todas as páginas do website, uma vez que as evidências apresentadas refletem problemas recorrentes e críticos, como textos alternativos incorretos, uso inadequado de atributos e padrões inconsistentes. A correção deve ser aplicada de forma transversal, garantindo que a acessibilidade seja tratada como padrão e não apenas nos apontamentos aqui colocados.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #68 Problemas de contraste para texto normal

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 6.1

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

  Evidências:

  • Contraste inferior para elementos textuais, elementos da interface e objetos gráficos.

  O website apresenta problemas de contraste. A evidência (1) revela problemas no rácio de contraste nos rótulos na página “Serviços” os textos que utilizam a cor #3E4242 e #56A295 como cor de plano de fundo. Não passam na avaliação de contraste. (Figura 1)

  

  Figura 1 - Texto normal com problemas de contraste com uma taxa de apenas 3,4:1

  A evidência (2) revela problemas no rácio de contraste nos rótulos do “Formulário comunicação de Ocorrências”, os textos que utilizam a cor #6BCABA e #FFFFFF como cor de plano de fundo. Não passam na avaliação de contraste. (Figura 2)

  

  Figura 2 - Texto normal com problemas de contraste com uma taxa de apenas 1,95:1

  A evidência (3) revela problemas no rácio de contraste do menu principal da página, os textos que utilizam a cor #FFFFFF e #F2AA00 como cor de plano de fundo. Não passam na avaliação de contraste. (Figura 3)

  

  Figura 3 - Texto normal com problemas de contraste com uma taxa de apenas 2:1

  URLs a verificar

  • (1) NOK https://www.cm-pombal.pt/servicos
  • (2) NOK. https://www.cm-pombal.pt/formulario-comunicacao-de-ocorrencias
  • (3) NOK https://www.cm-pombal.pt/inicio

  Recomendações
  Recomendamos a revisão das cores das páginas as combinações de cores utilizadas em texto normal incluindo estados de foco e hover para garantir os valores mínimos de contraste, é necessário a revisão dos pares de cores (cor de primeiro plano e cor de plano de fundo) em todo o website para assegurar visibilidade do conteúdo para todos os utilizadores.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #111 Vídeo não recebe foco quando se navega por leitor de ecrã

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 7.1

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

  Evidências:
  Verificámos que não é possível focar com o leitor de ecrã (setas direcionais) no vídeo Pombal Cinco Sentidos - O meu coração bate por Pombal, na página Pombal é Desporto.

  

  Figura – Análise do vídeo Pombal Cinco Sentidos - O meu coração bate por Pombal, na página Pombal é Desporto, através do Google Inspector.

  URL a verificar:
  Página Pombal é Desporto - Vídeo Pombal Cinco Sentidos - O meu coração bate por Pombal.

  Recomendações:
  A forma como o elemento está estruturado no HTML afeta a forma como os leitores de ecrã o interpretam. Analisando brevemente o código, recomendamos:

  • Evitar colocar vários links dentro do mesmo <p> - O <p> é um elemento semântico de texto. Quando contém múltiplos links, o leitor de ecrã pode interpretar o bloco como texto contínuo, deixando de expor o segundo link como elemento focável em modo de leitura.

  • Rever a necessidade de utilizar <p> para estruturar layout - O <p> deve ser usado apenas para conteúdo textual. Neste caso, está a ser utilizado para fins de layout, o que pode introduzir ambiguidades semânticas e afetar a forma como os leitores de ecrã interpretam os elementos interativos.

  • Aplicar espaçamento através de CSS - O uso de   introduz texto artificial dentro do parágrafo, reforçando a interpretação errada do bloco. O espaçamento entre elementos deve ser controlado exclusivamente via CSS.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #115 O idioma das legendas é diferente do idioma do vídeo

  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

  Notas gerais:
  A narração, áudio ou audiodescrição dos conteúdos multimédia devem estar no mesmo idioma do site, para que os utilizadores consigam aceder ao conteúdo na língua que escolheram, principalmente quando não têm fluência no outro idioma.

  Evidências:
  No vídeo Pombal Cinco Sentidos - O meu coração bate por Pombal, disponível na página Pombal é Desporto, está a ser narrado em português mas tem legendas abertas em inglês.

  

  Figura - Vídeo Pombal Cinco Sentidos - O meu coração bate por Pombal com legendas em inglês.

  URL a verificar:
  Página Pombal é Desporto - Vídeo Pombal Cinco Sentidos - O meu coração bate por Pombal.

  Recomendações:
  Recomendamos que essas legendas em inglês sejam substituídas por legendas fechadas em português, permitindo que o utilizador ative ou desative as legendas conforme necessário. Estas legendas devem incluir não só o diálogo, mas também sons relevantes, como música, ruídos ou indicações do ambiente, para garantir uma compreensão completa do vídeo.
  Recomendamos também que seja disponibilizada uma transcrição textual em português, de modo a assegurar o acesso ao conteúdo por parte de todos os utilizadores, incluindo aqueles que não possam ver ou ouvir o vídeo.

• evidência: issue #114 Não há legendas nos reprodutores de multimédia

  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

  Notas gerais:
  As legendas devem descrever todos os sons de um conteúdo multimédia que esteja a ser reproduzido (como música, efeitos sonoros e conversas). De preferência, as legendas devem poder ser ligadas e desligadas, como acontece nas legendas de filmes (ex: Netflix).

  Evidências:
  Verificámos que nos vídeos Trail Run Sicó e 3ª Corrida dos Gambuzinos, disponíveis na página Pombal é Desporto, não existem legendas nem transcrição textual dos conteúdos.

  

  Figura 1 – Vídeo 3ª Corrida dos Gambuzinos.

  

  Figura 2 – Vídeo Trail Run Sicó.

  URL a verificar:
  Página Pombal é Desporto - Vídeos Trail Run Sicó e 3ª Corrida dos Gambuzinos.

  Recomendações:

  • Adicionar legendas fechadas — Todos os vídeos do website devem incluir legendas fechadas, que apresentam não só o diálogo, mas também sons relevantes (por exemplo, música, ruídos, indicações de ambiente).
  • Disponibilizar transcrições textuais — Cada vídeo deve ter uma transcrição completa, permitindo o acesso ao conteúdo por utilizadores que não possam ver ou ouvir o vídeo e facilitando a consulta e pesquisa da informação.

• evidência: issue #113 Não existe audiodescrição do vídeo

  etiqueta: chk 10 webetiqueta: melhoriaetiqueta: R 7.2

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

  Notas gerais:
  Os vídeos que passam mensagens apenas percetíveis à visão devem conter uma audiodescrição, que é fundamental para que as pessoas cegas ou com baixa visão possam compreender o conteúdo exibido.

  Evidências:
  O vídeo Pombal Athletics – Pombal é Desporto, disponíveis na página Pombal é Desporto, não possui audiodescrição.

  

  Figura - Vídeo Pombal Athletics – Pombal é Desporto.

  URL a verificar:
  Página Pombal é Desporto - Vídeo Pombal Athletics – Pombal é Desporto.

  Recomendações:
  Recomendamos que seja adicionada uma audiodescrição ao vídeo em questão.

• evidência: issue #112 Não existe audiodescrição do vídeo

  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

  Notas gerais:
  Os vídeos que passam mensagens apenas percetíveis à visão devem conter uma audiodescrição, que é fundamental para que as pessoas cegas ou com baixa visão possam compreender o conteúdo exibido.

  Evidências:
  Os vídeos Trail Run Sicó e 3ª Corrida dos Gambuzinos, disponíveis na página Pombal é Desporto, não possuem audiodescrição.

  

  Figura 1– Vídeo Trail Run Sicó.

  

  Figura 2 – Vídeo 3ª Corrida dos Gambuzinos.

  URL a verificar:
  Página Pombal é Desporto - Vídeos Trail Run Sicó e 3ª Corrida dos Gambuzinos.

  Recomendações:
  Recomendamos que seja adicionada uma audiodescrição aos vídeos em causa.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #126 A faixa de aviso está posicionada depois do rodapé

  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

  Evidências:
  A faixa de avisos que está sendo apresentada na página inicial, está estruturalmente posicionada depois do footer:

  

  Recomendações:
  O último conteúdo da página deve ser o rodapé. Por esse motivo, devem posicionar a faixa de avisos acima dele no HTML.

• evidência: issue #91 O botão do menu compacto (mobile e tablet) está visível para leitores de ecrã em desktop

  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

  Evidencias
  Com o leitor de ecrã VoiceOver, é possível identificar o botão do menu compacto na versão desktop, utilizando o navegador Safari. Por exemplo, no website da Câmara Municipal de Guimarães, o menu é identificado como uma opção dentro da navegação mesmo estando ocultado via CSS:

  

  Botão menu visível dentro da navegação em desktop do website CM Guimarães

  

  No código é possível identificar que o menu está escondido via CSS e mesmo assim está a ser lido

  URL
  https://www.cm-pombal.pt/

  Recomendações

  • Deve ser utilizado o atributo aria-hidden tanto no menu desktop como no menu compacto. O menu que estiver visível no momento deverá ter aria-hidden="false", enquanto o outro deverá manter aria-hidden="true".

• evidência: issue #89 Existem elementos que estão a ser lidos apenas pelos leitores de ecrã

  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

  Evidencias

  As subopções do menu “Acesso rápido” encontram-se estruturadas no HTML após as opções “Ocorrências” e “Balcão Digital”. Para além disso, estas subopções estão visíveis no código mesmo quando o menu não se encontra expandido.

  Esta implementação faz com que, ao navegar para as subopções de “Acesso rápido”, seja necessário percorrer previamente as opções “Ocorrências” e “Balcão Digital”. Adicionalmente, o facto de as subopções estarem expostas às tecnologias de apoio mesmo quando não foram abertas pelo utilizador pode causar confusão na navegação e comprometer a experiência de utilização, em particular para utilizadores de leitores de ecrã:

  

  Opções de “Acesso rápido” visíveis para o leitor de ecrã mesmo não estando expandido do website da CM de Pombal

  

  As subopções estão estruturadas no HTML depois das opções de “Ocorrências” e “Balcão Digital” do website da CM de Pombal

  URL
  https://www.cm-pombal.pt/

  Recomendações

  • Relativamente ao campo de pesquisa, é necessário verificar todos os locais onde este é apresentado, garantindo que não é utilizada uma label associada a botões do tipo type="image".
  • Para as subopções de “Acesso rápido”, estas devem ser estruturadas de seguida e antes das opções “Ocorrências” e “Balcão Digital”. Devem garantir que as subopções apenas ficam visíveis quando a opção “Acesso rápido” se encontra expandida. Para esse efeito, recomenda-se a efetuarem correcções identificadas também na issue #26 .

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #88 Existem elementos interativos (links, botões) estruturados com a tag div

  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

  Evidencias

  Ao desativar o CSS, é possível identificar links e botões que não possuem semântica adequada, uma vez que estão a ser estruturados com divs. Esta prática pode causar problemas de navegação utilizando o teclado e com leitores de ecrã, pois estes elementos não recebem foco via teclado nem são corretamente anunciados pelos leitores de ecrã.

  Por exemplo, no website da CM de Pombal, a opção de "Acesso rápido" está sendo estruturada como uma div:

  

  Não é possível aceder ao link com o teclado através das teclas TAB e SHIFT + TAB no topo da página da CM de Pombal

  

  Leitor de ecrã não anuncia que é um link ou um botão no topo da página da CM de Pombal

  

  Na estrutura a opção "Acesso rápido" está como div no topo da página da CM de Pombal

  Recomendações

  • É importante garantir que todos os elementos interativos do website — como botões, links, controlos de carrosséis, modais, galerias de imagens e outros elementos acionáveis — sejam construídos utilizando elementos nativos do HTML.
  • Deve ser dada especial atenção aos elementos que atualmente só podem ser acionados com o rato, pois na maioria dos casos isto indica uma ausência de semântica adequada no código. A verificação deve focar-se principalmente nos controlos de carrosséis, modais, galerias de imagens e outros elementos interativos críticos, garantindo que todos possam ser utilizados sem dependência exclusiva do ponteiro do rato.

• evidência: issue #84 Tab estruturada de forma inapropriada

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Evidencias

  No website da CM de Pombal, existe um componente tab que não está estruturado de forma adequada. Para além de não ser possível identificá-lo como um tabulador através de leitores de ecrã, existem outros aspetos que deveriam ser implementados para garantir o seu correto funcionamento com o teclado e leitores de ecrã. Por exemplo:

  • Ao aceder ao conteúdo de uma tab, deve ser possível saltar das opções para o respetivo conteúdo com a tecla TAB.
  • O painel do tabulador deve ser corretamente identificado para que o leitor de ecrã perceba que se trata de uma área de conteúdo associada a cada tab.

  

  Leitor de ecrã não identifica como um tabulador(separador) e não é possível fazer o salto para o conteúdo apresentado

  

  Leitor de ecrã não informa que está dentro do conteúdo do tabulador (painel de separador)

  

  Exemplo de construção de uma tab pela W3C indica que é um tabulador, o número de opções e o painel do separador e é possível fazer o salto para o conteúdo com a tecla TAB

  URL
  https://www.cm-pombal.pt/

  Recomendações

  • É necessário garantir que o tabulador seja construído de forma adequada. Para isso, utilizem os atributos ARIA role="tablist", role="tab" e role="tabpanel", para indicar aos leitores de ecrã que se trata de um tabulador.
  • Para garantir uma interação apropriada, utilizem aos atributos aria-selected, aria-controls e tabindex, em conjunto com JavaScript.
  • Para mais informações partilhamos o exemplo de construção de TAB da W3C e documentação sobre as propriedades role="tab"

• evidência: issue #69 O leitor de ecrã identifica mais opções do que é apresentado visualmente no carrossel

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 8.3

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

  Evidências:
  O carrossel existente na secção “Em destaque” da página inicial do Município de Pombal apresenta os seis elementos visíveis para os leitores de ecrã:

  

  Carrossel que mostra todos os itens aos leitores de ecrã

  Sugestão de correção:

  Recomendamos que os elementos mostrados aos leitores de erã sejam exatamente aqueles que são mostrados visualmente de cada vez, para que os utilizadores destas tecnologias tenham a mesma experiência de navegação dos demais utilizadores.

  Para mais informações é possível consultar os artigos Carousel Structure e Carousel (Slide Show or Image Rotator) Pattern do W3C.

• evidência: issue #56 Carrosséis que exibem conteúdos automaticamente e não permitem pausar

  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

  Descrição do problema:

  O carrossel existente na secção “Em destaque” da página inicial do Município de Pombal não permitem pausar a passagem dos elementos.

  

  Para além disso, não informam quantos itens fazem parte do carrossel,

  Recomendamos que seja indicado visualmente o número de elementos de cada carrossel, e que a navegação seja exclusivamente controlada pelo utilizador, que, para além dos dois botões para avançar e retroceder, pode incluir 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: issue #55 Faixas de avisos que exibem conteúdos automaticamente e não permitem pausar

  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

  Evidencias:

  Os itens da secção avisos presente na página inicial estão sempre a passar e não permitem pausar com o teclado ou leitor de ecrã:

  

  _Faixa de avisos pausado apenas com o rato

  URL
  https://www.cm-pombal.pt/ - faixa inicial

  Recomendações

  • Deve ser possível pausar a faixa de avisos quando posicionamos o foco do teclado e leitor de ecrã.
  • Outra alternativa seria incluir um botão de pausar.

• evidência: issue #4 O conteúdo do glossário não está estruturado como uma lista de definição

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

  Evidencias
  O glossário foi estruturado utilizando as tags dl, dd, dt. Contudo, o índice do glossário é um grupo de links na qual não está estruturado como lista ul li :

  

  URL
  https://www.cm-pombal.pt/ficha-tecnica/declaracao-de-acessibilidade-e-usabilidade/glossario-de-termos-complexos-ou-tecnicos

  Recomendações
  Estruturar os links do índice como uma lista ul li. A sinalética visual "|" deve ser removida da estrutura e inserida via CSS.

• evidência: issue #3 Não é possível distinguir as diferentes navegações da página com o leitor 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

  Evidencias

  Quando uma página possui mais de uma área de navegação, é importante nomear cada nav par que os utilizadores de leitores de ecrã entendam a finalidade de cada seção de navegação.

  Verificou-se que a navegação está dividida entre o menu principal e o menu lateral. Nestes casos, e de acordo com as recomendações, ambas as áreas de navegação encontram-se corretamente estruturadas com o elemento nav. No entanto, torna-se agora necessário nomeá-las de forma adequada, de modo a permitir a sua distinção e identificação clara.

  

  Leitor de ecrã identifica duas navegações e não é possível distingui-las

  URL
  https://www.cm-pombal.pt/municipio - todas as páginas do website

  Recomendação
  O menu principal e o lateral devem ser nomeados de uma forma que seja possível distingui-los. Para isso, podem utilizar o aria-label.

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #116 Não foram encontradas modais

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

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

  Evidências
  Não foram encontradas modais no site da Câmara Municipal de Pombal. Assim, este requisito é avaliado como “Não Aplicável” (N/A).

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #117 Não foram encontradas modais

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

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

  Evidências
  Não foram encontradas modais no site da Câmara Municipal de Pombal. Assim, este requisito é avaliado como “Não Aplicável” (N/A).

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #118 Não foram encontradas modais

  etiqueta: chk 10 webetiqueta: N/Aetiqueta: 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

  Evidências
  Não foram encontradas modais no site da Câmara Municipal de Pombal. Assim, este requisito é avaliado como “Não Aplicável” (N/A).

etiqueta: N/A

Lista de evidências recolhidas:

• evidência: issue #119 Não foram encontradas modais

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

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

  Evidências
  Não foram encontradas modais no site da Câmara Municipal de Pombal. Assim, este requisito é avaliado como “Não Aplicável” (N/A).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #70 Preservação do texto em PDF

  etiqueta: chk 10 webetiqueta: NOKetiqueta: R 10.1

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

  Evidencia

  O teste de usabilidade que consta na declaração possui tabelas cujo conteúdo não é extraível:

  

  Conteúdo das tabelas não são extraíveis

  URL
  https://www.cm-pombal.pt/ficha-tecnica/declaracao-de-acessibilidade-e-usabilidade

  Recomendação
  Todo o conteúdo deve ser extraível para um processador de texto. Para isso, podem utilizar ferramentas de OCR como o da Adobe por exemplo.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #39 Etiquetas dos campos de preenchimento possuem tamanho abaixo do recomendado

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.1

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

  Evidencias

  Verifica-se a existência de formulários cujo tamanho de fonte da etiqueta está abaixo do recomendado (16 pixels). Por se tratar de uma informação essencial para o correto preenchimento do formulário, consideramos este elemento como informação primária, devendo, portanto, ter um tamanho mínimo de 16 pixels.

  

  Etiqueta do campo de pesquisa com tamanho de 14px

  URL
  https://www.cm-pombal.pt/visitar/eventos

  Recomendações

  • É necessário rever todos os formulários e campos de pesquisa, assegurando que o tamanho das etiquetas (labels) seja, no mínimo, de 16 pixels.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #36 Os blocos de texto possuem tamanho maior que 100 caracteres

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 2.3

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

  Evidencias

  Existem páginas com blocos de conteúdos com tamanho acima de 100 caracteres:

  

  Bloco de texto com tamanho de 114 caracteres

  URL

  • https://www.cm-pombal.pt/municipio/transparencia/regime-geral-da-prevencao-da-corrupcao-rgpc
  • https://www.cm-pombal.pt/municipio/transparencia/indice-da-presenca-na-internet-das-camaras-municipais-portuguesas-1
  • https://www.cm-pombal.pt/municipio/transparencia/projetos-cofinanciados/urbact#faq-2

  (necessário corrigir todas as páginas do website)

  Recomendação

  Devem definir uma largura máxima para as caixas de texto (max-width, em CSS), com unidades relativas ao tamanho de fonte (unidades em ou rem) para garantir que não é ultrapassado o número máximo de caracteres por linha.

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

Lista de evidências recolhidas:

• evidência: issue #122 Breadcrumbs não representam corretamente a localização do utilizador

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

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

  Evidências:
  Verificámos que, no site da Câmara Municipal de Pombal, as breadcrumbs não representam corretamente a localização do utilizador.

  

  Figura – Página Alojamento Local. O caminho de breadcrumbs (Início > Visitar > Onde Dormir?) que aparece na página está incompleto. Breadcrumbs destacada através de um retângulo de borda preta.

  Recomendações:
  Recomendamos reformular este componente para que apresente, de forma precisa, a página onde o utilizador se encontra e o trajeto desde a página inicial.

• evidência: issue #121 Estrutura do menu lateral não é percetível

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

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

  Evidências:
  Verificámos que no site da Câmara Municipal de Pombal foram incluídos menus laterais nas páginas de interior. Notámos que, visualmente, estes menus não tornam evidente a estrutura hierárquica da navegação, dificultando a perceção do nível em que o utilizador se encontra e da sua localização dentro do site.

  

  Figura – Menu lateral do site do Município de Pombal na página de interior Horta Biológica.

  Recomendações:
  Deve ser feita uma revisão da estrutura do menu de forma a tornar a hierarquia mais clara, melhorar a identificação do nível de navegação e garantir que o utilizador compreende facilmente onde está e para onde pode ir a seguir.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #16 Documentos longos sem índice

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

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

  Evidências:

  O website, possui páginas longas que sem índice. Por exemplo, a página de “Política de Privacidade e Termos de Utilização” apresenta-se como uma página longa, mas não disponibiliza um índice no topo com hiperligações internas para cada bloco de conteúdo. Além disso, visualmente são separados por títulos que não estão estruturados corretamente. (Figura 1)

  

  Figura 1 - Páginas longas sem índice e mal estruturadas semanticamente

  Sem um índice inicial os utilizadores especialmente aqueles que recorrem a tecnologias de apoio, podem perder a referência da sua localização na página, prejudicando a compreensão e a eficiência na navegação.

  Além disso, os acordeões presentes na página não estão estruturados corretamente, apresentam-se com o conteúdo totalmente expandido. E na navegação com leitores de ecrã, não é percetível se a componente está expandida ou recolhida, anunciada apenas como link. (Figura 2)

  

  Figura 2- Acordeões com problemas de acessibilidade

  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.

  URLs a verificar

  • https://www.cm-pombal.pt/ficha-tecnica/politica-de-privacidade-e-termos-de-utilizacao
  • https://www.cm-pombal.pt/ficha-tecnica/declaracao-de-acessibilidade-e-usabilidade
  • (Índice em formato de texto não estão atribuídos como hiperligações internas)
  • https://www.cm-pombal.pt/municipio/transparencia/indice-da-presenca-na-internet-das-camaras-municipais-portuguesas-1
  • (Problemas na funcionalidade de acordeões, apresentam-se totalmente expandidos)
  • https://www.cm-pombal.pt/ficha-tecnica/mapa-do-site

  Recomendações
  Para facilitar a navegação em páginas longas, recomendamos adicionar índices no início das páginas longas com hiperligações para cada secção interna.

  • É necessário rever e corrigir os acordeões do website para garantir que sejam estruturados corretamente, para que seu conteúdo seja percetível e acessível para todos utilizadores.
  • Recomendamos também rever as notas relativas ao critério 8.3 da checklist dos 10 aspetos, nomeadamente no que diz respeito à semântica dos elementos interativos (acordeões) e aos títulos que, apesar de separarem visualmente blocos de conteúdo nas páginas longas, não se encontram corretamente definidos como cabeçalhos.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #15 O layout do sítio Web é adaptável a plataforma móveis

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

  Evidências:

  • 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.

  A evidência (1) revela que o campo de pesquisa não se adapta às diferentes resoluções de ecrã, pois sobrepõe os elementos interativos das redes sociais do Município. O mesmo problema se repete nas páginas principais de todo o website. (Figura 1)

  

  Figura 1 - Erro de responsividade no website Pombal

  URLs a verificar

  • (1) NOK. https://www.cm-pombal.pt/

  Recomendação
  Recomendamos rever e corrigir espaçamento e margens responsivas entre as áreas clicáveis. Para garantir que todo o layout do site, especificamente seus textos possuem comportamento responsive e adaptam-se às diferentes resoluções de ecrã, sem necessidade de fazer varrimento horizontal para realizar a leitura dos conteúdos.

etiqueta: NOK

Lista de evidências recolhidas:

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

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.1

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

  Evidências:

  Na Página inicial, os controlos do carrossel destaque de notícias são acionados apenas através da interação por hover. Ao passar o rato, surgem as setas interativas. (Figura 01)

  

  Figura 01 - Carrossel destaque de notícias com controlos ativos apenas com hover

  O website disponibiliza uma componente para galerias de fotos, com controlos diponíveis apenas com hover. Por exemplo na página O que Visitar? (Figura 2)

  

  Figura 2 - Setas interativas na galeria de imagens disponível com hover

  Quando um elemento interativo depende exclusivamente do hover para ser ativado ou para revelar informação, torna-se inacessível para utilizadores que recorrem a tecnologias de apoio, bem como para quem utiliza dispositivos móveis baseados em toque. Esta limitação compromete a perceção da funcionalidade e impede o acesso equitativo ao serviço disponibilizado.

  URLs a verificar

  • https://www.cm-pombal.pt/ (Setas interativas do banner de notícias em destaque)
  • https://www.cm-pombal.pt/visitar/o-que-visitar (Carrosel de galeria com setas de controlo ativas apenas com hover)

  Recomendação
  Garantir que os elementos interativos podem ser accionados através de outros tipos de interação como o teclado, toque e tecnologias de apoio para que o conteúdo seja apresentado de forma visível e acessível sem depender exclusivamente do hover.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #13 Os elementos interativos têm uma dimensão mínima de 44px

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.2

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

  Evidências:

  • Para garantir que os utilizadores interagem devidamente com um elemento interativo (botões, imagens-link...), a área clicável desse elemento deve ser, no mínimo, 44px de largura e 44px de altura.

  A evidência (1) revela na página inicial, há elementos interativos com área clicável que não cumprem a dimensão mínima exigida (44px de altura e largura). Por exemplo os botões “Acesso rápido”, “Ocorrências” e “Balcão digital” que possuem altura de 27.2px, não cumprindo as dimensões mínimas necessárias.

  

  A evidência (2) revela na página “Município”, há elementos interativos com área clicável que não cumprem a dimensão mínima exigida (44px de altura e largura). Por exemplo os botões das redes sociais “Partilhar e-mail”, “Partilhar no messeger”, “Partilhar no Whatsaap”, “Partilhar no Linkedin” e “Partilhar no facebook” com tamanho de 40x40px, não cumprindo as dimensões mínimas necessárias.

  

  URLs a verificar

  • (1) NOK. https://www.cm-pombal.pt/
  • (2) NOK https://www.cm-pombal.pt/municipio

  Recomendações
  Devem garantir que os elementos interativos têm uma altura e largura igual ou superior a 44px de área clicável. Adicionalmente, recomenda-se que ícones visível mantenham uma proporção equilibrada face à área clicável, mesmo que o elemento gráfico (ícone/imagem) apresente dimensões inferiores, assegurando uma identificação clara e uma ativação cómoda.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #12 Há apenas um botão de ação principal por página e o mesmo encontra-se destacado

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.3

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

  Evidências:

  • Os botões de ação principal devem estar destacados numa página ou num bloco de informação para tornar mais perceptível o local onde os utilizadores devem clicar para realizar uma determinada tarefa.

  A evidência (2) revela que na página “Comunicar Ocorrências” o botão de ação principal “Voltar” não têm destaque suficiente face aos restantes botões da página.

  

  URLs a verificar

  • (1) OK. https://www.cm-pombal.pt/
  • (2) NOK https://www.cm-pombal.pt/comunicar-ocorrencias

  Recomendação geral
  Os botões principais devem ser estilizados de forma diferente dos botões de ação secundária. Pode-se também distinguir os botões através da forma (ex: preenchimento, delineamento, cantos arredondados).

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #11 Elementos interativos devem aparentar ser clicáveis

  etiqueta: NOKetiqueta: chk conteúdoetiqueta: R 5.4

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

  Evidências:

  • Os elementos interativos devem ter um estilo que demonstre que são clicáveis e, ao mesmo tempo, suficientemente diferente de elementos não clicáveis para que não se confundam.
  • O contraste em elementos interativos deve ser de, no mínimo, 3:1 em relação a cor adjacente. Este contraste é aplicado a todos os estados dos elementos (normal, hover, focus, etc). Quando o elemento possui conteúdo em texto, o contraste deve ser de no mínimo, 4,5:1 com a cor de fundo.

  A evidência (2) demonstra que a página “Newsletters” contém elementos interativos com contraste insuficiente. O botão “Subscrever”, por exemplo, utiliza a cor #6bcaba, que apresenta um contraste de apenas (1,9:1) face ao fundo, tornando‑se difícil de perceber, especialmente para pessoas com baixa visão.

  

  URLs a verificar

  • (1) NOK. https://www.cm-pombal.pt/newsletters-65

  Recomendações
  Recomendamos a revisão das cores dos vários estados dos elementos para garantir os valores mínimos de contraste em elementos interativos.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #29 A sequência de tabulação não segue a sequência de preenchimento nos documentos PDF

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

  Evidências
  Na análise o ficheiro PDF disponível na página Requerimento de Benefícios Fiscais através do browser e do Adobe Acrobat Reader, e foi verificado que é um formulário longo cujo conteúdo está distribuído por 2 páginas, respetivamente.
  No entanto, como este formulário PDF não está acessível, os utilizadores que dependem de leitores de ecrã não conseguem aceder devidamente ao seu conteúdo. (Figura 1)

  

  Figura 1 - Formulário PDF inacessível através do Browser

  Apesar de ser possível navegar com as setas direcionais com leitor de ecrã NVDA e Adobe Reader, e realizar a leitura do documento. Não há direcionamento do foco para os campos de preenchimento, por exemplo em checkbox da secção "Visita Técnica" e a navegação por teclado (Tab e Shift+Tab) não funciona, sendo assim não cumprem o presente requisito. (Figura 2)

  

  Figura 2 - Análise do formulário Requerimento de Benefícios Fiscais com leitor de ecrã NVDA no Adobe Acrobat Reader.

  URLs a verificar

  • Formulário PDF disponível na página Requerimento de Benefícios Fiscais

   

  Recomendações
  Recomenda-se que para formulário PDF, a solução mais acessível seria disponibilizar o formulário diretamente no site, em vez de em formato PDF.

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

Lista de evidências recolhidas:

• evidência: issue #28 Formulários PDF inacessíveis para leitores de ecrã

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

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

  Evidências
  Na análise o ficheiro PDF disponível na página Requerimento de Benefícios Fiscais através do browser e do Adobe Acrobat Reader, e foi verificado que é um formulário longo cujo conteúdo está distribuído por 2 páginas. No entanto, como este formulário PDF não está acessível, os utilizadores que dependem de leitores de ecrã não conseguem aceder devidamente ao seu conteúdo. (Figura 1)

  

  Figura 1 - Formulário com divisão por páginas inacessível no browser

  Embora seja possível aceder ao conteúdo com o leitor de ecrã NVDA em conjunto com o Adobe Reader, a navegação fica limitada ao uso das teclas direcionais, seguindo apenas a ordem de leitura do documento. No entanto, a navegação por teclado através das teclas (Tab e Shift+Tab) não funciona, tal como a navegação por cabeçalhos. Por exemplo, não é possível perceber que há títulos separadores nas etapas de preenchimento "Observações" e "Envio de Correspondência (Preencher se for diferente da morada do requerente)". (Figura 2)

  

  Figura 2 - Análise do formulário Requerimento de Benefícios Fiscais com leitor de ecrã NVDA no Adobe Acrobat Reader navegação não funciona de forma faseada.

  Como consequência, toda a informação é apresentada de forma contínua e pouco estruturada, sendo transmitida ao utilizador de uma só vez. Esta abordagem dificulta a compreensão e torna impercetível a separação por secções ou etapas do formulário.

  URLs a verificar

  • Formulário PDF disponível na página Requerimento de Benefícios Fiscais

   

  Recomendações
  Recomenda-se que para formulário PDF, a solução mais acessível seria disponibilizar o formulário diretamente no site, em vez de em formato PDF.

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

Lista de evidências recolhidas:

• evidência: issue #27 Formulários PDF inacessíveis para leitores de ecrã

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

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

  Evidências
  Na análise o ficheiro PDF disponível na página Requerimento de Benefícios Fiscais através do browser e do Adobe Acrobat Reader, e foi verificado que é um formulário longo cujo conteúdo está distribuído por 2 páginas.

  Apesar de o formulário apresentar uma sequência de passos ilustrada e estar dividido em seis etapas (por exemplo, “Identificação do Requerente”, “Localização do Imóvel”, entre outras), não é acessível na sua navegação. (Figura 1)

  

  Figura 1 - Formulário longo em PDF, inacessível pelo browser, comprime toda informação de uma vez e não possível navegar pelo teclado

  Embora seja possível aceder ao conteúdo com o leitor de ecrã NVDA em conjunto com o Adobe Reader, a navegação fica limitada ao uso das teclas direcionais, seguindo apenas a ordem de leitura do documento. A navegação por teclado através das teclas (Tab e Shift+Tab) não funciona, tal como a navegação por cabeçalhos. Sendo assim, não é possível perceber que há títulos separadores nas etapas de preenchimento "Observações" e "Envio de Correspondência (Preencher se for diferente da morada do requerente)". (Figura 2).

  

  Figura 2 – Análise com leitor de ecrã NVDA e Adobe Reader, formulário não é funcional para preenchimento digital e apresenta-se inacessível na navegação por teclado e leitor de ecrã.

  URLs a verificar

  • Formulário PDF disponível na página Requerimento de Benefícios Fiscais

   

  Recomendações
  Recomenda-se que para formulário PDF, a solução mais acessível seria disponibilizar o formulário diretamente no site, em vez de em formato PDF.

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

  Evidências:

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #130 Existem campos cuja legenda não é clara

  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

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

  Evidências:
  Verificámos que, no formulário PDF “Requerimento de Benefícios Fiscais”, presente na página Requerimento de Benefícios Fiscais, existem campos cuja legenda não é clara como, por exemplo, “Inscrito na Matriz” e “COD. POSTAL”.

  

  Figura - Formulário em PDF “Requerimento de Benefícios Fiscais” presente na página Requerimento de Benefícios Fiscais.

  URL a verificar:
  Página Requerimento de Benefícios Fiscais

  Recomendações:
  Recomendamos que estes dois rótulos sejam alterados para deixar mais claro a informação a inserir (por exemplo, “Código-Postal”). Além disso, sugerimos evitar o uso de maiúsculas em todos os caracteres, pois isso pode dificultar a leitura e a compreensão, especialmente para pessoas que utilizam leitores de ecrã.

• evidência: issue #129 O texto placeholder está visualmente a substituir o rótulo

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

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

  Notas gerais:
  Não deve ser usado o texto placeholder em substituição de uma label, porque ao escrever no campo esse texto irá desaparecer e torna a tarefa difícil para pessoas com problemas de memória ou na revisão das respostas do formulário. Para além disso, alguns leitores de ecrã podem não estar preparados para ler esse texto.
  Adicionalmente, ao 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.

  Evidências:
  Nos campos de pesquisa presentes no cabeçalho do site e na página de Pesquisa, cada campo tem uma label associada. No entanto, essa label não está visível no ecrã — apenas é lida por leitores de ecrã.

  

  Figura 1 – Análise do campo de pesquisa geral, presente no cabeçalho do site, através do Google Inspector.

  

  Figura 2 – Análise do campo de pesquisa, presente na página Pesquisa, através do Google Inspector.

  URL a verificar:

  • Página Pesquisa
  • Campo de pesquisa no cabeçalho do site

  Recomendações:
  Recomendamos a revisão dos formulários para garantir que:
  • o texto placeholder, quando utilizado, auxilia no preenchimento do campo em vez de substituir a legenda;
  • caso seja usada a legenda dentro do campo, esta deve estar identificada como <label> e não deve desaparecer quando o campo está em foco, como acontece no exemplo do Campos de formulário - Material Design e/ou Caixa de seleção - Material Design
  Para mais informações, recomendamos consultar a página sobre boas práticas nos formulários da WebAIM.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #132 Não é possível identificar campos obrigatórios nos formulários em PDF

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

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

  Evidências:
  Verificámos que, no formulário PDF “Requerimento de Benefícios Fiscais”, na página Requerimento de Benefícios Fiscais, não é possível reconhecer os campos de preenchimento obrigatório. Esta informação não é passada quer visualmente quer para os leitores de ecrã.

  

  Figura - Formulário em PDF “Requerimento de Benefícios Fiscais” disponível na página Requerimento de Benefícios Fiscais.

  URL a verificar:
  Página Requerimento de Benefícios Fiscais

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

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

• evidência: issue #131 Formulários PDF inacessíveis para leitores de ecrã

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

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

  Evidências:
  Testámos o formulário do ficheiros PDF “Requerimento de Benefícios Fiscais”, presente na página Requerimento de Benefícios Fiscais, através do browser e do Adobe Acrobat Reader, e não é possível navegar pelos diferentes campos do formulário através do leitor de ecrã.

  

  Figura – Análise do documento PDF “Requerimento de Benefícios Fiscais” através do Adobe Acrobat Reader e do leitor de ecrã NVDA.

  URL a verificar:
  Página Requerimento de Benefícios Fiscais

  Recomendações:
  Uma solução mais acessível seria disponibilizar o formulário diretamente no site, em vez de em formato PDF.

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #22 Em ações longas o sistema deve dizer o que está a acontecer

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

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

  Evidencias
  Quando submetemos alguns formulários do website, está sendo informado para os leitores de ecrã o que está sendo feito. Contudo, essa prática não está a acontecer com todos os formulários.

  O formulário de newsletter embora tenha um tempo de processamento, o leitor de ecrã não está a ser notificado sobre o carregamento das informações:

  

  Formulário submetido cujo processamento é avisado para as tecnologias de apoio

  

  Formulário submetido e nenhum aviso é notificado pelas tecnologias de apoio

  URL
  https://www.cm-pombal.pt/newsletters-65

  Recomendação

  • Garantir que os formulários notifiquem os leitores de ecrã de que algo está acontecendo, nesse caso, o envio das informações do formulário.
  • Exemplo de formulário do website que notifica sobre o envio do formulário: https://www.cm-pombal.pt/municipio/assembleia-municipal/inscricao-para-intervencoes-do-publico

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

Lista de evidências recolhidas:

• evidência: issue #21 O Sucesso do envio/submissão da informação é confirmada

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

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

  O critério está a cumprir, mas é possível fazer melhorias: em alguns formulários do website o foco não está a ser direcionado para a mensagem automaticamente:

  

  Foco do leitor de ecrã não é posicionado automaticamente na mensagem

  

  Foco do leitor de ecrã é posicionado automaticamente na mensagem

  

  Foco do leitor de ecrã é posicionado automaticamente na mensagem

  URL
  https://www.cm-pombal.pt/sugestoes-reclamacoes-elogios

  Recomendação
  O foco deve ser posicionado na mensagem de confirmação, assim como os outros formulários do website.
  Exemplo de formulários com foco posicionado na mensagem de confirmação:

  • https://www.cm-pombal.pt/pages/416?error_code=0
  • https://www.cm-pombal.pt/resultados_pesquisa?search_terms=teste

etiqueta: N/A

Lista de evidências recolhidas:

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

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

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

etiqueta: NOK

Lista de evidências recolhidas:

• evidência: issue #18 Existem campos sem mensagens de erro programaticamente associadas

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

  Evidências:
  O campo “Aceito que o sistema me envie e-mails de resposta à presente submissão” do Formulário comunicação de Ocorrências não tem a sua mensagem de erro associada programaticamente:

  

  Isso acontece também nas checkboxes dos formulários Sugestões, Reclamações, Elogios Newsletter Inscrição para intervenções do público e Participação no Período de Intervenção do Público

  URLs a verificar:

  • Formulário comunicação de Ocorrências
  • Sugestões, Reclamações, Elogios
  • Newsletter
  • Inscrição para intervenções do público
  • Participação no Período de Intervenção do Público

  Recomendações:
  Recomendamos o uso dos atributos aria-describedby (ou aria-errormessage) com o id do container da mensagem de erro e aria-invalid nos campos com mensagem de erro, tal como já é feito nas textboxes e comboboxes de todos os formulários.

etiqueta: NOK

Lista de evidências recolhidas:

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

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

  Evidências:
  A mensagem de erro “É necessário que 'Contacto telefónico:' seja um número válido” apresentada no campo “Contacto de telefone”, nos formulários Inscrição para intervenções do público e comunicação de Ocorrências não informa de forma clara quais os passos necessários para corrigir o erro. As mensagens de erro devem ser claras, sucintas e indicar concretamente como o utilizador pode resolver o problema:

  

  Mensagem de erro associada ao campo Contacto telefónico do formulário “Inscrição para intervenções do público”

  URLs a verificar:

  • Inscrição para intervenções do público
  • comunicação de Ocorrências

  Recomendações:
  Recomendamos rever todos os formulários do website para garantir que as mensagens de erro apresentadas expliquem para o utilizador como preencher os campos corretamente.

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

Lista de evidências recolhidas:

• evidência: issue #10 Outras Violações - Conteúdos incompletos/vazios em páginas interiores

  etiqueta: melhoriaetiqueta: outras violações

  Evidências:

  Há páginas no website com conteúdos vazios ou incompletos. Por exemplo na página App Mobile, verificam-se conteúdos com informação incompleta ou não desenvolvida, apresentam apenas o texto “Brevemente disponível”, sem conteúdo informativo adicional disponível para o utilizador. (Figura 1)

  

  Figura 1 - Conteúdo não desenvolvido com mensagem “Brevemente disponível”

  Esta situação resulta na apresentação de uma secção estruturalmente existente, mas semanticamente vazia do ponto de vista informativo, podendo gerar expectativas de conteúdo que não se encontram cumpridas.

  A presença de conteúdos incompletos pode afetar a experiência de utilização, uma vez que o utilizador é exposto a uma área de informação que aparenta estar em falta ou em desenvolvimento. Em contexto institucional, este tipo de ausência de conteúdo pode causar frustração, comprometer a clareza e a completude da informação disponibilizada.

  URLs a verificar:

  • https://www.cm-pombal.pt/download-da-app-mobile
  • https://www.cm-pombal.pt/sondagens
  • https://www.cm-pombal.pt/municipio/comunicacao/revista-municipal

  Recomendações:

  • Garantir que todas as secções de conteúdo visíveis possuem informação efetiva e completa;
  • Substituir mensagens temporárias como “Brevemente disponível” por conteúdo informativo real ou remover a secção até existir informação disponível;
  • Caso o conteúdo ainda esteja em desenvolvimento, considerar ocultar a secção para evitar exposição de áreas vazias na interface.

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

  etiqueta: melhoriaetiqueta: outras violações

  Evidências

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

  Na página Comunicar Ocorrências, existe uma hiperligação que direciona para um serviço externo ao aceder a hiperligação “Reporte-nos a sua ocorrência aqui” o utilizador é direcionado para página com erro. (Figura 1)

  

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

  

  Figura 2 - Link externo da Página com erro

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

  URLs a verificar

  • https://www.cm-pombal.pt/comunicar-ocorrencias

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

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